On Wed, 8 Nov 2006 02:20:37 -0800 Chris Wright wrote: > * Zack Weinberg ([email protected]) wrote: > > Presently, the security checks for syslog(2) apply also to access to > > /proc/kmsg, because /proc/kmsg's file_operations functions just call > > do_syslog, and the call to security_syslog is in do_syslog, not > > sys_syslog. [The only callers of do_syslog are sys_syslog and > > kmsg_{read,poll,open,release}.] This has the effect, with the default > > security policy, that no matter what the file permissions on > > /proc/kmsg are, only a process with CAP_SYS_ADMIN can actually open or > > read it. [Yes, if you open /proc/kmsg as root and then drop > > privileges, subsequent reads on that fd fail.] In consequence, if one > > wishes to run klogd as an unprivileged user, one is forced to jump > > through awkward hoops - for example, Ubuntu's /etc/init.d/klogd > > interposes a root-privileged "dd" process and a named pipe between > > /proc/kmsg and the actual klogd. And ALT Linux uses exactly the same patch as you have posted :) klogd starts as root, opens /proc/kmsg, then chroots to a directory which contains just the dev/log socket and drops all privileges. > The act of reading from /proc/kmsg alters the state of the ring buffer. > This is not the same as smth like dmesg, which simply dumps the messages. > That's why only getting current size and dumping are treated as > less-privileged. But in order to read from /proc/kmsg, you need to open() it first - and that operation is restricted both by DAC checks on /proc/kmsg and by do_syslog(1,NULL,0) call in kmsg_open(). (However, the patch by Zack effectively removes that access check, which is probably not good for SELinux.) > > I propose to move the security_syslog() check from do_syslog to > > sys_syslog, so that the syscall remains restricted to CAP_SYS_ADMIN in > > the default policy, but /proc/kmsg is governed by its file > > permissions. With the attached patch, I can run klogd as an > > unprivileged user, having changed the ownership of /proc/kmsg to that > > user before starting it, and it still works. Equally, I can leave the > > ownership alone but modify klogd to get messages from stdin, start it > > with stdin open on /proc/kmsg (again unprivileged) and it works. > > > > I think this is safe in the default security policy - /proc/kmsg > > starts out owned by root and mode 400 - but I am not sure of the > > impact on SELinux or other alternate policy frameworks. > > SELinux doesn't distinguish the entrypoint to the ringbuffer, > so this patch would break its current behaviour. Then what would you think about another solution: 1) When sys_syslog() is called with commands 2 (read) or 9 (get unread count), additionally call security_syslog(1) to check that the process has permissions to open the kernel log. This change by itself will not make any difference, because all existing implementations of the security_ops->syslog hook treat the operation codes 1, 2 and 9 the same way. 2) Change cap_syslog() and dummy_syslog() to permit commands 2 and 9 for unprivileged users, in addition to 3 and 10 which are currently permitted. This will not really permit access through sys_syslog() due to the added security_syslog(1) check, but if a process somehow got access to an open file descriptor for /proc/kmsg, it would be able to read from it. Also, because selinux_syslog() is not changed, under SELinux the process will still need to have additional privileges even if it has /proc/kmsg open. Two patches will follow.
Attachment:
pgpJ7MXtRnGRj.pgp
Description: PGP signature
- Follow-Ups:
- References:
- Prev by Date: [PATCH] sysctl: Undeprecate sys_sysctl
- Next by Date: Re: [PATCH] i386: make BUG() expansion look like instruction
- Previous by thread: Re: RFC PATCH: apply security_syslog() only to the syslog() syscall, not to /proc/kmsg
- Next by thread: [RFC PATCH 1/2] sys_syslog: check open permission for reading and getting unread count
- Index(es):
 |