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 20:14:00 -0800
From:	Chris Wright <chrisw@...s-sol.org>
To:	Sergey Vlasov <vsu@...linux.ru>
Cc:	Chris Wright <chrisw@...s-sol.org>,
	Zack Weinberg <zackw@...ix.com>, linux-kernel@...r.kernel.org,
	sds@...ho.nsa.gov, jmorris@...ei.org
Subject: Re: RFC PATCH: apply security_syslog() only to the syslog() syscall, not to /proc/kmsg

* Sergey Vlasov (vsu@...linux.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
-
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/