Message-ID: <eb97335b0611091640i5bc149a5yb32f8f8581af3648@mail.gmail.com>
Date:	Thu, 9 Nov 2006 16:40:03 -0800
From:	"Zack Weinberg" <zackw@...ix.com>
To:	"Stephen Smalley" <sds@...ho.nsa.gov>
Cc:	"Chris Wright" <chrisw@...s-sol.org>,
	"Sergey Vlasov" <vsu@...linux.ru>, linux-kernel@...r.kernel.org,
	jmorris@...ei.org
Subject: Re: RFC PATCH: apply security_syslog() only to the syslog() syscall, not to /proc/kmsg

On 11/9/06, Stephen Smalley <sds@...ho.nsa.gov> wrote:
> On Thu, 2006-11-09 at 09:39 -0800, Zack Weinberg wrote:
> >  An open fd on /proc/kmsg
> > (with my changes applied) offers strictly fewer privileges than
> > SYSTEM__SYSLOG_MOD (no access to opcodes 4 and 5), and with SELinux
> > active, you can't get that open fd without having had
> > SYSTEM__SYSLOG_MOD at some prior time.
>
> Sure you can.  You can inherit or receive a descriptor opened by another
> process that had that permission (and even accidental descriptor leakage
> isn't as uncommon as you might think; SELinux has turned up numerous
> cases of it).

See, from my perspective, being able to pass this fd around is a
*feature*.  It lets me do things like

start-stop-daemon --start --chuid klog --chroot /var/run/klogd --exec
/sbin/klogd -- -x -P - -o - < /proc/kmsg > /dev/log

(hypothetical, does not work with unpatched klogd)

Being able to open /proc/kmsg subject only to standard DAC checks is
*also* a feature in my book.  In short, what you are saying reads to
me as "I don't want you to do the very thing you are trying to do."

I also think we wouldn't be having this discussion in the first place
if it weren't that /proc/kmsg was historically implemented on top of
sys_syslog() which *has* to do permission checks on the
read-equivalent, 'cos anyone can call that without having done any
open-equivalent first.

[...]
> > I see this as bringing /proc/kmsg in line with standard Unix file
> > permission semantics, overall.
>
> It may fit with Linux DAC checking, but it isn't what we want for MAC.
> You also have to be careful about drawing an analogy to typical Linux
> permission checking, since this is proc rather than a normal filesystem.

So let me back off and try to explain again what my goals are here.

I want to be able to run klogd as an unprivileged user, under the
default security model, possibly in a chroot jail; in particular it
should have to keep neither uid 0 nor CAP_SYS_ADMIN in order to read
from /proc/kmsg.  The logical way to accomplish this, to my mind, is
to subject /proc/kmsg to the normal Unix DAC checks and no more.  From
that reference frame, I see security_syslog as relevant to the
syslog() system call, which doesn't *have* DAC to rely on, and not to
/proc/kmsg.

Now, I see that the SELinux model is rather different, but I'm asking
you to consider the possibility of using the same "label" stuff for
/proc/kmsg that is used for all other file-based permissions in
SELinux.  If it would make it easier, I am prepared to do the
gruntwork of turning the thing into a misc character device or
something like that.  That way, security_syslog() could still be only
about access control for the syslog() system call.

Note that I'm perfectly fine with needing to apply special privileges
to klogd in a SELinux universe -- it's just that in the default model
one might as well not bother dropping privileges if one has to leave
CAP_SYS_ADMIN asserted.

> > But that mapping is itself a security policy decision, and could
> > plausibly need to be done differently in different security modules...
>
> Even the set of security hook interfaces and placements impose some
> limits on security policies that can be implemented.  But just as those
> hooks can be adjusted over time for the needs of new modules, the
> mapping can be adjusted over time as needed.  No harm done, and some
> benefit.

Hmm, okay, so the existing groupings that selinux/hooks.c has make
sense to me, except I'd split up SYSTEM__SYSLOG_MOD a bit ...

#define KLOG_CLOSE           0  /* Close the log  */
#define KLOG_OPEN            1  /* Open the log  */
#define KLOG_READ            2  /* Read from the log (klogd) */
#define KLOG_GET_UNREAD      9  /* Return number of unread characters */

 -> "can be klogd"

#define KLOG_READ_ALL        3  /* Read history of log messages (dmesg) */
#define KLOG_GET_SIZE       10  /* Return size of log buffer */

 -> "can be dmesg"

#define KLOG_READ_CLEAR_ALL  4  /* Read and clear history of log messages */
#define KLOG_CLEAR           5  /* Clear history of log messages */

 -> "can clear message history"

#define KLOG_DISABLE_CONSOLE 6  /* Disable printk's to console */
#define KLOG_ENABLE_CONSOLE  7  /* Enable printk's to console */
#define KLOG_SET_CONSOLE_LVL 8  /* Set level of messages printed to console */

 -> "can adjust console loglevel"

(#defines taken from the local <linux/syslog.h> that I've made up;
currently "can be klogd" and "can clear message history" are lumped
together; perhaps one should need both "can be dmesg" and "can clear
message history" for READ_CLEAR_ALL, but that might be too picky)

zw
-
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