¿Por qué es syslog un usuario?

Cuando reviso el /var/log, encuentro algo muy extraño

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

Tenga en cuenta que el propietario de los primeros cuatro archivos de registro es syslog. Es extraño, porque solo hay un usuario en mi sistema:

me@me~$ users
me

¿Por qué un nombre de archivo syslogpuede ser un usuario?

Tiene que ver con la seguridad y los permisos para acceder a su sistema.

Y no, tiene muchos más usuarios que solo su propio usuario. Hay "root", "daemon", "bin", "games", "nobody" y "list".

Haga una more /etc/passwdlista de usuarios en su sistema. Verá muchas líneas con "/ usr / sbin / nologin". Eso significa que no se puede usar como un usuario normal con un inicio de sesión como puede hacerlo su propio usuario. La tercera columna es la identificación del usuario. Todas las ID de usuario inferiores a 1000 son pseudousuarios. Su primer usuario de sudo (el que instaló el sistema) tiene 1000 por defecto.

Básicamente, el syslog del usuario puede usar el /var/log/directorio establecido como directorio propiedad de root . Para no tener que comprometer los permisos en el directorio (es decir, reducir los permisos para que otros usuarios puedan usarlo), se creó este usuario.

Lo mismo se hace con el usuario para Apache y MySQL (verá un usuario y grupo de www-data y un usuario y grupo de MySQL cuando instale estos), pero se usa para muchas cosas. Hay un grupo "marcado" que se utiliza para acceder a dispositivos externos. Los usuarios se agregan a este grupo para permitir que el usuario use estos dispositivos. De lo contrario, recibirá un error de permiso denegado. Funciona de dos maneras: negar el acceso de un usuario significa eliminar el grupo.

El servicio syslog, que escribe mensajes de registro creados por el kernel y por otros servicios en varios archivos de registro, la consola y / u otros destinos, se ejecuta bajo su propia cuenta de usuario especial. También lo hacen muchos otros servicios. Esto es para implementar el principio de menor privilegio :

Para minimizar el posible impacto de un servicio comprometido o defectuoso (por ejemplo, un servicio que tiene un error que a su vez es explotado por un atacante, o un servicio que tiene un error que causa es hacer cosas no deseadas al azar, o un servicio que ha sido diseñado deliberadamente por un desarrollador maligno para hacer cosas malas), desea que cada servicio tenga acceso solo a lo que necesita para su funcionamiento y nada más.

En cualquier sistema operativo similar a Unix (que incluye todas las distribuciones de GNU / Linux como Ubuntu), puede asignar privilegios más fácilmente (que es principalmente el derecho de leer y / o escribir desde / a ciertos archivos o cosas similares a archivos como nodos de dispositivo) en función de usuarios y grupos. Existen otras posibilidades, pero a menudo son más tediosas y propensas a errores de configuración, o funcionan solo en contextos específicos.

Entonces, el servicio syslog se ejecuta bajo la cuenta de usuario syslog. Si ahora, por ejemplo, un atacante puede hacer que el servicio de syslog haga lo que le dicen en lugar de lo que se supone que debe hacer, el servicio de syslog todavía está restringido (el núcleo lo aplica según la cuenta de usuario, no lo hace el syslog) software en sí, lo que sería inútil porque está comprometido) para escribir solo en los archivos de registro (los únicos archivos a los que el usuario de syslog tiene acceso de escritura). Por lo tanto, el atacante no puede utilizar el servicio de syslog comprometido para, por ejemplo, cambiar el contenido de un sitio web o una base de datos alojada en la misma computadora, porque los archivos relevantes están configurados para que se puedan escribir solo por un conjunto particular de otro usuario (humano o del sistema ) cuentas, no por la cuenta de usuario syslog.

Para causar más daño que simplemente eliminar / modificar los archivos de registro y leer archivos "públicos" (con permiso de "lectura" para todos), el atacante primero necesitaría explotar adicionalmente un segundo error, ya sea en el núcleo o en algún software que se instala para ejecutarse con diferentes privilegios que el usuario que lo invocó ( setuid ), y así obtener privilegios adicionales ( escalada de privilegios ).

---

El userscomando que usó, de acuerdo con su página de manual , muestra solo los usuarios que están actualmente conectados . Como el usuario de syslog es un usuario del sistema , nunca iniciará sesión, por lo que nunca aparecerá en esta lista. Puede examinar el archivo /etc/passwdo utilizar cualquiera de los otros métodos descritos aquí para obtener una lista de todos los usuarios (humanos y del sistema) en su sistema.

Porque syslog no es un archivo; Es un demonio utilizado por el sistema para almacenar el demonio del sistema y los mensajes de la aplicación (depuración, error, advertencia e información) en los archivos.

Lea aquí para una breve historia de syslog.

En otras distribuciones, por ejemplo, las basadas en Red Hat Linux, la salida de syslog para el sistema se almacena en un archivo llamado /var/log/messages. Depende de la configuración.

Como dice Rinzwind, por razones de seguridad, diferentes componentes del sistema operativo se ejecutan con un usuario específico, y cada usuario tiene sus propios derechos. Por ejemplo, syslog al menos tiene permiso de escritura en la /var/logcarpeta.

Un sistema tiene muchos servicios, y generalmente hay usuarios para cada servicio o para un pequeño grupo de servicios. Por ejemplo, apache get www-data|httpd|apache. Normalmente, estos usuarios de daemon no obtienen acceso a Bash para evitar fugas de seguridad.