On Fri, 2005-11-18 at 09:19 -0500, Stephen Smalley wrote: > On Thu, 2005-11-17 at 16:27 -0500, James Morris wrote: > > On Thu, 17 Nov 2005, Stephen Smalley wrote: > > > > > We then end up with only one new LSM here (SLIM) and two support > > > libraries. At which point the only motivator for stacker is combining > > > SLIM and SELinux without directly coupling them. > > > > I'm not clear on why we'd need SLIM when we have SELinux. > > > > How difficult would it be to implement a LOMAC policy in SELinux? > > The principle issue would be adding support for automatic demotion of > process integrity in response to reading of lower integrity data, which > is something we do not support in the Flask architecture by design > choice, as we don't agree with the idea of floating labels (pervasive > non-tranquility of security labels in the system which makes analysis > difficult, increased opportunity for application misbehavior due to > automatic downgrading, trend toward processes and objects always > devolving to the lowest integrity level (and highest secrecy level, if > using secrecy levels) over time). I think we'd favor configuring TE appropriately to provide Biba-style integrity (with proper confinement and protection of the "trusted" subjects there via the TE controls) rather than the LOMAC/SLIM approach. BTW, I think that much of the original motivation for LOMAC is OBE. The documentation and papers for LOMAC emphasized the difficulty in getting MAC mainstreamed and pitched LOMAC as an easily-adoptable form of MAC (based not only on its model but also on not needing any kernel or userspace patches), while admitting that LOMAC embodies a trade-off between the quality of MAC protection and compatibility. But SELinux has made major inroads in getting MAC into the mainstream and ongoing work on SELinux will further help with the remaining challenges there, rendering this tradeoff unnecessary. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Fri Nov 18 2005 - 06:41:46 PST