Почему системный журнал является пользователем?

Когда я проверяю /var/log, я нахожу что-то очень странное

me@me:~$ ls -lt /var/log |head -6 '
total 160368
-rw-r-----  1 syslog            adm              19919118 Jan 15 16:55 auth.log
-rw-r-----  1 syslog            adm             139702302 Jan 15 16:55 syslog
-rw-r-----  1 syslog            adm                191122 Jan 15 16:55 mail.log
-rw-r-----  1 syslog            adm               2210432 Jan 15 16:32 kern.log
-rw-r--r--  1 root              root              1741863 Jan 15 14:22 dpkg.log

Обратите внимание, что владельцем первых четырех файлов журнала является syslog. Это странно, потому что в моей системе только один пользователь:

me@me~$ users
me

Почему имя файла syslogможет быть пользователем?

Это связано с безопасностью и правами доступа к вашей системе.

И нет, у вас гораздо больше пользователей, чем просто ваш собственный пользователь. Есть "root", "daemon", "bin", "games", "nobody" и "list".

Сделайте more /etc/passwdдля списка пользователей в вашей системе. Вы увидите много строк с "/ usr / sbin / nologin". Это означает, что их нельзя использовать как обычный пользователь с таким же логином, как ваш собственный пользователь. Третий столбец - это идентификатор пользователя. Все идентификаторы пользователя ниже 1000 являются псевдопользователями. Ваш первый пользователь sudo (тот, кто установил систему) имеет 1000 по умолчанию.

В основном, пользовательский системный журнал может использовать /var/log/каталог, который установлен как каталог, принадлежащий пользователю root . Чтобы не подвергать риску разрешения для каталога (т. Е. Уменьшить разрешения, чтобы другие пользователи могли его использовать), этот пользователь был создан.

То же самое делается с пользователем для Apache и MySQL (вы увидите пользователя и группу www-данных и пользователя и группу MySQL при их установке), но это используется для множества вещей. Существует группа «Dialout», которая используется для доступа устройств к внешним устройствам. Пользователи добавляются в эту группу, чтобы позволить пользователям использовать эти устройства. В противном случае вы получите ошибку отказа в разрешении. Это работает двумя способами: отказ в доступе пользователя означает удаление группы.

Служба системного журнала, которая записывает сообщения журнала, созданные ядром и другими службами, в различные файлы журнала, консоль и / или другие места назначения, работает под собственной специальной учетной записью пользователя. Как и многие другие услуги. Это для реализации принципа наименьших привилегий :

Чтобы свести к минимуму возможное влияние скомпрометированной или неисправной службы (например, службы, у которой есть ошибка, которая, в свою очередь, используется злоумышленником, или службы, имеющей ошибку, которая вызывает случайные нежелательные действия, или службы, которая был специально разработан злостным разработчиком для выполнения плохих действий), вы хотите, чтобы каждый сервис имел доступ только к тому, что ему нужно для своей работы, и ничего больше.

В любой Unix-подобной операционной системе (которая включает в себя все дистрибутивы GNU / Linux, такие как Ubuntu) вы можете легко назначать привилегии (которые в основном являются правом чтения и / или записи из / в определенные файлы или файлы, подобные файлам, такие как узлы устройства) на основе пользователей и групп. Существуют и другие возможности, но они часто более утомительны и подвержены ошибкам при настройке, либо работают только в определенных контекстах.

Итак, служба syslog работает под учетной записью syslog. Если, например, теперь злоумышленник может заставить службу системного журнала делать то, что ему говорят, вместо того, что он должен, служба системного журнала все еще ограничена (обеспечивается ядром на основе учетной записи пользователя, а не системным журналом). само программное обеспечение, которое было бы бесполезным, потому что оно скомпрометировано) для записи только в файлы журнала (единственные файлы, к которым у пользователя системного журнала есть доступ для записи). Таким образом, злоумышленник не сможет использовать угрозу системного журнала услугу , например , изменить содержание веб - сайта или базы данных , размещенных на том же компьютере, потому что соответствующие файлы настроены быть доступны для записи только некоторым определенным набором другого (человека или системы ) пользователя учетные записи, а не по учетной записи пользователя системного журнала.

Чтобы нанести больше вреда, чем просто удалить / изменить файлы журнала и прочитать «публичные» файлы (с разрешением «чтение» для всех), злоумышленнику сначала потребуется дополнительно использовать вторую ошибку, либо в ядре, либо в некотором программном обеспечении. он устанавливается для запуска с привилегиями, отличными от пользователя, который его вызвал ( setuid ), и, таким образом, получает дополнительные привилегии ( повышение привилегий ).

---

Команда, которую usersвы использовали, согласно ее man-странице , показывает только тех пользователей, которые в данный момент вошли в систему . Поскольку пользователь системного журнала является системным пользователем , он никогда не будет входить в систему, поэтому он никогда не будет отображаться в этом списке. Вы можете просмотреть файл /etc/passwdили использовать любой другой метод, описанный здесь, чтобы получить список всех (человек и система) пользователей в вашей системе.

Потому что системный журнал - это не файл; это демон, используемый системой для хранения системных демонов и сообщений приложений (отладка, ошибка, предупреждение и информация) в файлах.

Читайте здесь для краткой истории системного журнала.

В других дистрибутивах, например, основанных на Red Hat Linux, вывод системного журнала для системы хранится в файле с именем /var/log/messages. Это зависит от конфигурации.

Как говорит Ринзвинд, по соображениям безопасности разные компоненты операционной системы работают с определенным пользователем, и у каждого пользователя есть свои права. Например, системный журнал, по крайней мере, имеет разрешение на запись в /var/logпапку.

Система имеет много сервисов, и обычно есть пользователи для каждого сервиса или для небольшой группы сервисов. Например, apache get www-data|httpd|apache. Обычно эти пользователи-демоны не получают доступ к Bash, чтобы избежать утечек в системе безопасности.