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

[Chris Wright <chrisw@sous-sol.org>]

* Sergey Vlasov (vsu@altlinux.ru) wrote:
> 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.

It's a bit clumsy in the extra caveats for sys_syslog and cap_syslog,
but does achieve what you're after.  We lose default checking on the
actual read access, but perhaps this is a fair tradeoff.  Stephen,
James do you have any issues with this for SELinux?

thanks,
-chris