On 11/9/06, Stephen Smalley <[email protected]> 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 [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]
