Re: Adding support for SE-Linux security

On Fri, 2009-12-11 at 14:11 -0500, Stephen Frost wrote:
> All,
> 
> * Robert Haas (robertmhaas@gmail.com) wrote:
> > If we design a security abstraction layer, the interfaces need to
> > really be abstraction boundaries.  Passing the table OID and then also
> > the tablespace OID because PG DAC needs that to make its access
> > control decision is crap.  
> 
> Now, to address the small useful bit of this mail- I tend to agree with
> this.  I'm not convinced there's an alternative, but I'd like to throw
> out a couple of my ideas on how it could be addressed.  I'd like to
> solicit for feedback on these.
> 
> First off, we have alot of the information available from the catalog.
> Basically, given an OID, we should be able to find out the other
> information associated with that OID (such as what kind of object it is,
> what tablespace it resides in, etc).  OID isn't sufficient, however, as
> we know from the dependency system.  To address this, we would need OID
> and SubOID.  Now, any information which we can derive from those should
> not be included in the API.  To be honest, I don't think we've actually
> been all that bad about this, but I'll reserve any definitive answer
> until I've gone back through the API we have specifically thinking about
> this issue.  On further thought, I'm probably wrong and should have
> caught this during my review.  Sorry.
> 
> Second, the information we *don't* have from above is generally
> information about what the requesting action is.  For example, when
> changing ownership of an object, we can't possibly use introspection to
> find out the role which is on the receiving end, since at that time
> we've just learned it from the parser.  Now, we might build an entire
> new object, pass the "result of this action" OID to the security system
> and ask it "can we change OID X into OID Y?", but I don't particularly
> like it.  We really don't want to do any *changes* to things until after
> we've determined the permissions allow for it, and I'm not sure how to
> get around that without building an independent introspection system for
> "what might be".  Perhaps we're comfortable enough saying "we'll just
> rollback the command if it turns out to have not been allowed" but I
> just don't like it.  Feels like a higher risk solution to me.
> 
> I don't see a way to get around the second piece since what information
> is needed about the action is typically action-specific.  Perhaps we
> could have an 'action-ID' (uh, we have an ID per command already, no?
> Probably doesn't fit the mold close enough though), and then a way to
> query information about "what is this action trying to do?".  Doesn't
> seem likely to be very clean though.
> 
> Other thoughts?

In the Linux LSM case, we define a separate hook interface for each
logical operation/action, where hook name identifies the
action/operation and the set of arguments to that hook interface are the
complete set of inputs that may be relevant to deciding whether to
permit the operation/action.   These arguments typically include
pointer(s) to one or more object data structures as well as ancillary
arguments (e.g. new owner value if chown).  Reference:
http://www.usenix.org/event/sec02/wright.html
http://lxr.linux.no/#linux+v2.6.32/include/linux/security.h

The XACE framework for the X server is described by:
http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html
Unlike the LSM framework, it passes resource identifiers rather than
direct object pointers.

The FreeBSD MAC framework is described by:
http://www.freebsd.org/doc/en/books/arch-handbook/mac.html
It provides more abstraction than LSM does, at a cost in the overhead of
the framework itself.

-- 
Stephen Smalley
National Security Agency