Re: [RFC] [Stacking v4 2/3] New version of SELinux patch to support stacking

From: Serge Hallyn (serue@private)
Date: Tue Dec 07 2004 - 12:31:26 PST


Digsig is quite orthogonal to SELinux and capabilities, so I don't think
there would be any reason why it couldn't be stacked through stacker.
Valdis wanted his module to behave differently based on whether SELinux
was loaded.  This isn't quite the same as his results depending on
SELinux results, though, so it might still be loadable through stacker.

Valdis, Joshua, Makan, am I wrong about that?  I don't want to stop
anything from working, but if possible I think that drawing the line
between (1) stacking two independing LSMs and (2) loading two
cooperating LSMs would be useful.

Incidentally, digsig currently cannot be loaded under SELinux because it
uses inode->i_security and file->f_security.  So lsm-chain.patch would
still need to be applied and used by digsig+selinux whether or not
stacker was used.

thanks,
-serge

On Tue, 2004-12-07 at 13:41 -0500, Stephen Smalley wrote:
> On Tue, 2004-12-07 at 14:17, Serge Hallyn wrote:
> > Does SELinux expect any other LSM to be loaded as secondary than
> > capability?  Could the secondary_ops stuff be replaced by capability-
> > specific code?
> 
> For our purposes, yes; we could just as easily call the cap_* functions
> directly from the SELinux hook functions.  Some people (Valdis, Joshua)
> have experimented with using the secondary_ops for other security
> modules (openwall-like restrictions, digsig) that do not need to use the
> security fields, and we did add some additional secondary_ops calls for
> that purpose a while back, but they likely could just use the stacker
> module instead.
> 
> We could also change calls to capable() from SELinux hook functions to
> instead call selinux_capable(), as that would still ensure that both
> capability and SELinux checking was applied and avoid the nested stacker
> calls in those cases.  However, we'd still have nested stacker calls
> when the cap_* functions call capable() internally.  But in those cases,
> that might be desired anyway by other modules.
> 
-- 
Serge Hallyn <serue@private>



This archive was generated by hypermail 2.1.3 : Tue Dec 07 2004 - 11:19:46 PST