On Fri, 2005-11-18 at 09:47 -0500, Stephen Smalley wrote: > > 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). In contrast, we have found the low water-mark model to be very useful in practice. To each, his own. Here is a justification for LSM and choice of MAC modules. > 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. While LOMAC as an implementation is certainly OBE, low water-mark as a model is not. The trade-offs were in the security of LOMAC's implementation, not in the security of the underlying low water-mark model. In fact, Biba published a security proof for the low water-mark model, while I am not aware of any such proofs for Type Enforcement. Anyway, our main concern here is to give users the options for integrity verification, integrity attestation, and low water-mark MAC, whether as LSM modules, or libraries, or as policies, or whatever. We deeply appreciate all of the suggestions, and would like reach some sort of consensus as to an acceptable architecture on which to move forward. dave safford
This archive was generated by hypermail 2.1.3 : Fri Nov 18 2005 - 11:39:23 PST