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

From: Makan Pourzandi (Makan.Pourzandi@private)
Date: Wed Dec 08 2004 - 12:22:51 PST


Serge Hallyn wrote:
> 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.

My 2 cents: IMO, the best scenario is that both should be possible, 
though the first case seems to be straight forward and very useful. The
example that first comes to my mind for stacking two independent modules 
is stacking digsig with SE Linux (say 2 orthogonal modules). As these 
modules are orthogonal there is no problem for them to decide on an 
operation. The composition policy "operation allowed if all modules 
allow it" is ok and covers all cases here. This stacking allows one to 
add the extra functionality not yet in SE Linux to the system and test it.

Regarding the second case, it's reasonable to believe that some people 
would always have their own "specific" modules that could never get into 
main stream Linux (and SE Linux). For example, you can write your own 
kernel module becasue in your clustered server, you need  kernel level 
support to run your own distributed security mechanisms. This kind of 
modules can never get into main stream because of their nature which 
make them specific to a particular field. I believe that there are other 
examples too. The second case would allow people to use SE Linux as base 
and add their own functionality on top of it for their "specific" needs. 
Now, I understand that this is not perhaps the most secure way of using 
SE Linux, or BTW any other primary security module and there are many 
problems solving the interactions between 2 modules but generally this 
kind of work would mature over time and gives additional steam for Linux 
security (like many other open source projects). I believe what I try to 
say is that the second case can be an enabler or a catalyzer for 
developing new security functinality for Linux in general. Well, back to 
the subject, in this latter case the composition policy "operation 
allowed if all modules allow it" seems to be the best choice.


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


Makan Pourzandi, Open Systems Lab
Ericsson Research, Montreal, Canada
*This email does not represent or express the opinions of Ericsson Inc.*

This archive was generated by hypermail 2.1.3 : Wed Dec 08 2004 - 13:47:11 PST