[prev in list] [next in list] [prev in thread] [next in thread] 

List:       selinux
Subject:    Re: I am more worried about open then read and write, SELinux
From:       Stephen Smalley <sds () tycho ! nsa ! gov>
Date:       2008-01-24 13:33:20
Message-ID: 1201181600.21288.33.camel () moss-spartans ! epoch ! ncsc ! mil
[Download RAW message or body]


On Thu, 2008-01-24 at 08:08 -0500, Stephen Smalley wrote:
> On Wed, 2008-01-23 at 17:01 -0500, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > One of the things I have talked about in the past was separating the
> > access for open from read/write.
> > 
> > 
> > An example of where this is a problem is the following AVC from a
> > bugzilla I got today.
> > type=AVC msg=audit(1201052518.765:1352): avc: denied { write } for
> > pid=5767 comm="dbus-daemon" path="/home/zack/startx.log" dev=sda3
> > ino=2227350
> > scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023
> > tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
> > 
> > 
> > This indicates that zack started x windows with startx.  With its
> > standard output directed to /home/zack/startx.log.  The avc indicates
> > that dbus has suddenly started trying to write files in the users home
> > directory.
> > 
> > My choice is to allow it or dontaudit it.
> > 
> > Neither is correct.  I really want to know if a confined application
> > suddenly opens a file in the users homedir for writing, but if the
> > processes is handed an open file descriptor, I want to allow it.
> > 
> > This is a fundamental flaw in the usability of SELinux.  Handling of
> > stdin/stdout/stderr are always generating AVC messages that we either
> > cover up or allow, and this can prevent us from discovering a real
> > cracker situation.
> > 
> > I would like to propose that we add one or more avc's to deal with
> > opening a file.  open or open_read open_write.  Leave the existing
> > access for those that are worried about leaking file descriptors and
> > information flow, but allow us to concentrate on real vulnerability s
> > versus noicy avc messages.
> 
> I'm not opposed to adding an open permission check - we just need to do
> it in a way that preserves compatibility (i.e. no denials for legacy
> systems, especially for akpm's test boxes).  That means at present that
> we need to use the policy capability mechanism introduced by Paul Moore
> to selectively enable/disable this check depending on whether the policy
> was built with a new capability indicating that it supports the new
> check.  Unfortunately, the handle unknown support isn't sufficient as
> there are legacy distros that don't have it enabled (in fact, AFAIK,
> only Fedora 8 has it enabled - unless you've back ported the
> checkpolicy/libsepol support to Fedora 7 and rebuilt policy there with
> handle_unknown = allow, which would be helpful btw).
> 
> The other delicate point is that this check would apply to all file
> classes, yet we can't add permissions to the common definitions at
> present as that would disturb the existing per-class definitions.  So
> we'd have to add this new permission per-class, and have a mapping array
> or function that maps each class to the right permission for use at the
> permission check call site.
> 
> To do it, we need:
> 1) someone to implement the kernel side support, including adding a new
> policy capability, adding the new permission, and implementing the new
> check with a conditional test on the new capability.
> 2) someone to implement the libsepol/checkpolicy side support in order
> to allow policies to be built that turn on the capability.
> 3) someone to go through policy and either manually decides now where to
> add open permissions or just create a script that automatically inserts
> open everywhere there is read or write on a file class and then later
> gradually pare down the use of open to only where needed.

BTW, given that it entails a non-trivial amount of work, it would be
good to roll in any other desired permission additions at the same time
if possible.  For example, we've also talked about adding a 'map' check
on mmap and mprotect so that we can distinguish memory mapped access
(since it has different implications for revocation).

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
[prev in list] [next in list] [prev in thread] [next in thread]