Hi, 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. Regards Makan > 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