linux-kernel - Re: RFC PATCH: apply security_syslog() only to the syslog() syscall, not to /proc/kmsg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 8 Nov 2006 02:20:37 -0800
From:	Chris Wright <chrisw@...s-sol.org>
To:	Zack Weinberg <zackw@...ix.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: RFC PATCH: apply security_syslog() only to the syslog() syscall, not to /proc/kmsg

* Zack Weinberg (zackw@...ix.com) 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.

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.

> 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.

thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/