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

From: Chris Wright
Date: Wed Nov 08 2006 - 23:12:06 EST


* Sergey Vlasov (vsu@xxxxxxxxxxx) 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/