* Sergey Vlasov ([email protected]) 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
