Re: RFC PATCH: apply security_syslog() only to the syslog()syscall, not to /proc/kmsg

[Stephen Smalley]

On Thu, 2006-11-09 at 09:39 -0800, Zack Weinberg wrote:
> On 11/9/06, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
> > Unless I missed something, your plan above would disable SELinux
> > syslog-related permission checking upon reads of a previously opened
> > file descriptor to /proc/kmsg.  So it would change SELinux behavior in a
> > way that is directly contrary to the notion of mandatory access control.
> 
> Yes, it would do that; no, I don't see why that change is contrary to
> the notion of mandatory access control.  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).

>   SELinux does not (as far as I
> can tell) do MAC checks for access to normal files at read() time,
> only open().

Look for security_file_permission() calls in the core code, and its
implementation in SELinux (selinux_file_permission).  That is just a
revalidation of access to help with relabeling and policy changes,
albeit necessarily incomplete in coverage.  More crucially, SELinux
rechecks descriptors on inheritance across execve
(flush_unauthorized_files) and transfer across local IPC
(selinux_file_receive) to prevent unauthorized propagation of access
rights in the first place.  

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

> > But having a mapping in the core to a much
> > smaller set of permissions would be even better, and help with
> > maintenance; the next time someone added a new code, they would more
> > likely see the mapping table in the core and update it than go digging
> > into the individual security modules.
> 
> 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. 

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/