Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler <casey@schaufler-ca.com>]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> ...
> 
> > Good suggestion. In fact, that is exactly how I approached my
> > first two attempts at the problem. What you get if you take that
> > route is an imposing infrastructure that has virually nothing
> > to do and that adds no value to the solution. Programming to the
> > LSM interface, on the other hand, allowed me to drastically reduce
> > the size and complexity of the implementation.
> 
> It would be interesting to see the result of those first two attempts
> (even if they didn't get very far) just to see your approach and what
> obstacles you ran up against.

Woof. It weren't pretty, and I've carefully archived it so as
to make it hard to go back to for that very reason. Maybe someday.
 
> ... 
> > Smack is not a subset of SELinux, it behaves differently. SELinux
> > has a policy that is program behavior oriented, Smack is strictly
> > subjet/object oriented. Your 4 components (A-D) are meaningless to
> > Smack.
> 
> To clarify, SELinux is also based on subjects and objects grouped into
> equivalence classes (labels), and the granularity at which one applies
> protection is configurable, so you can certainly have very
> coarse-grained labels that don't require any specific knowledge of
> application behavior.  A type is just a security equivalence class - it
> doesn't have to map to an application at all.
> 
> Also, the idea behind SELinux was that its policy engine (security
> server, security/selinux/ss/*) could be replaced with other
> implementations without affecting the rest of SELinux if someone wanted
> to try radically different logic.  The interface to that policy engine
> is itself general and not tied to TE.

The ss interface provides no advantage over the LSM interface that
I can see.

> > > >>> I'm not yet annoyed enough to go implement an iptables like  
> > > >>> interface to the LSM enhancing it with more generic mechanism to  
> > > >>> make the problem simpler, but I'm getting there.  Perhaps next  
> > > >>> time  I'm bored.
> > > >>
> > > >> I think a fair amount of what we need is already done in SELinux,  
> > > >> and efforts would be better spent in figuring out what seems too  
> > > >> complicated in SELinux and making it simpler.
> > 
> > The granularity and consequently the size of the policy specificiation
> > result in policies that are too complicated. Tieing the policy to the
> > expected behavior of specific applications adds to the complexity.
> 
> Well, it reveals the complexity already present in the system, and gives
> you the option of controlling it.  Your choice as to at what granularity
> to apply it.

Which is the same for LSM. There are a bunch of LSM hooks that Smack
does not need, and going into SELinux code to choose to do nothing
is pretty pointless.

> > SELinux is designed to increase in complexity as it evolves. Making
> > it simpler would conflict with the design goal of finer granularity.
> > 
> > > >> Probably a fair amount  of that just means better tools.
> > 
> > Now what kind of tools are you talking about? Static analysis?
> > Data flow diagrammers for Java?
> > 
> > > > How about thinking of it another way.
> > > >
> > > > Perform the split up you talked about above and move the table  
> > > > matching into the LSM hooks.
> > > >
> > > > Use something like the iptables action and match to module mapping  
> > > > code so we can have multiple modules compiled in and useable at the  
> > > > same time with the LSM hooks.
> > > >
> > > > I think it is firmly established that selling SElinux to everyone  
> > > > is politically untenable.  However enhancing the LSM (even if it is  
> > > > mostly selinux code movement down a layer) I think can be sold.
> > 
> > That would be silly. Smack uses a significantly smaller set of hooks
> > than SELinux requires and still does interesting things. We went through
> > the "replace LSM with the SELinux interface" exercise a couple years
> > ago, I would hate to have to regurgitate all those discussions.
> 
> I don't think Eric is proposing replacing LSM with the SELinux interface
> as it exists today, but rather making LSM more Netfilter-like and
> radically refactoring SELinux (and any other security module) to consist
> of a chain of smaller modules that are more general and reusable, and
> that can be composed and applied in interesting ways via an
> iptables-like interface.  I'm not sure what that would look like
> exactly, but it seems reasonable to explore.

The image that just flashed into my brain had a disturbing
similarity to STREAMS modules, but spread everywhere, not just
in the tty code. And anyone who thinks that there are too many
LSM hooks now would have kittens over this. I don't think it's a
bad idea, but I don't see how it would change the well documented
disputes regarding what kinds of security behavior it ought to
provide for. How would it help AppArmor, for example? I'm willing
to bet (a beer or equivalence) that anything that helped there
would face stiff resistance simply because it helped there.

I could see it working if you restricted the interface to dealing
with things that have security blobs, or even better to subjects
and objects. But that's my security mindset, and I think pretty
much yours, too. It's the policies that don't use good old
fashioned OrangeBook concepts that have issue, not SELinux or Smack.

> One of the things left unresolved with LSM is userland API, and it does
> involve more than just returning EPERM or EACCES to applications.  You
> already have patched ls and sshd programs, and have acknowledged the
> need for more userland modifications to ultimately achieve your own
> goals.  If LSM is going to succeed in the kernel, then ultimately you
> need some common API for userland so that you don't need separate
> versions of ls, ps, sshd, etc for Smack vs SELinux vs. whatever.

Smack uses text strings for labels. It's amazing how many of the API
issues evaporate when the only thing you have to do with your labels is
compare them and print them. With the labels for processes available
through /proc, and the labels for most things available via getxattr(2)
and its variants the API issue seems hard to get worked up about. If
ls(1) had an option to show selected extended attributes, and it really
should by now, it wouldn't require fixing at all. Now sshd, login, and
the rest of the authentification gaggle are going to need policy
specific behavior so I feel no serious need to provide common API there.
Smack is designed to make this easy because I had to do it the hard
way before and didn't like it much.



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