When I check the /var/log
, I find something very strange
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
Notice that the owner of the first four log file is syslog
. It's weird, because there is only one user on my system:
me@me~$ users
me
Why could a filename syslog
be a user?
It has to do with security and permissions on accessing your system.
And no, you have a lot more users than just your own user. There is "root", "daemon","bin", "games", "nobody", and "list".
Do a
more /etc/passwd
for a list of users on your system. You will see lots of lines with "/usr/sbin/nologin". That means those can not be used as a normal user with a login like your own user can. The third column is the user ID. All user IDs below 1000 are pseudo users. Your 1st sudo user (the one that installed the system) has 1000 by default.Basically user syslog is allowed to use the
/var/log/
directory that is set as a directory owned by root. To not have to compromise permissions on the directory (i.e., lower the permissions so other users can use it), this user was created.The same is done with the user for Apache and MySQL (you will see a www-data user and group and a MySQL user and group when you install these), but it is used for loads of things. There is a group "dialout" that is used to access devices to externals. Users get added to this group to allow the user to use these devices. Otherwise you will get a permission denied error. It works two ways: denying a user access means removing that user from the group.
The syslog service, which writes log messages created by the kernel and by other services to various log files, the console, and/or other destinations, runs under its own, special user account. So do many other services. This is to implement the principle of least privilege:
In order to minimize the possible impact of a compromised or faulty service (e.g. a service that has a bug which in turn gets exploited by an attacker, or a service that has a bug that causes is to do random undesired things, or a service that has been deliberately designed by a malignant developer to do bad things), you want each service to have access only to what it needs for its operation and nothing else.
On any unix-like operation system (that includes all GNU/Linux distributions such as Ubuntu), you can most easily assign privilieges (that is mostly the right to read and/or write from/to certain files or file-like things such as device nodes) based on users and groups. There are other possibilities, but they are often more tedious and error-prone to set up, or work only in specific contexts.
So, the syslog service runs under the syslog user account. If now, for example, an attacker can get the syslog service to do what they tell it to instead of what it is supposed to, the syslog service is still restricted (enforced by the kernel based on the user account, not enforced by the syslog software itself, which would be useless because it is compromised) to write only to the log files (the only files to which the syslog user has write access). Thus, the attacker can not use the compromised syslog service to e.g. change the contents of a website or database hosted on the same computer, because the relevant files are set up to be writable only by some particular set of other (human or system) user accounts, not by the syslog user account.
In order to cause more harm than just deleting/modifying the log files and reading "public" files (with "read" permission for everyone), the attacker would first need to additionally exploit a second bug, either in the kernel or in some software that is installed to run with different privileges than the user that invoked it (setuid), and thus gain additional privileges (privilege escalation).
The
users
command you used, according to its man page, shows only the users that are currently logged in. Since the syslog user is a system user, it will never log in, so it will never show up in this list. You can look into the file/etc/passwd
or use any of the other methods described here to get a list of all (human and system) users on your system.Because syslog is not a file; it is a daemon used by the system to store system daemon and application messages (debug, error, warn, and info) to files.
Read here for a brief history of syslog.
In other distributions, for example those based on Red Hat Linux, the syslog output for the system is stored in a file called
/var/log/messages
. It depends on configuration.As Rinzwind says, for security reasons different components in the operating system run with a specific user, and each user has their own rights. For example, syslog at least has write permission on the
/var/log
folder.A system has many services, and there are usually users for each service or for a small group of services. For example,
apache get www-data|httpd|apache
. Normally these daemon users do not get Bash access to avoid security leaks.