[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061109041400.GB6602@sequoia.sous-sol.org>
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/
Powered by blists - more mailing lists