On Wed, 18 Apr 2001, Casey Schaufler wrote: > Don't forget other popular policies, including the No Checks > policy, Bell & LaPadula, Biba, NT (no endorsement implied), > and no-SUperUser-capabilties. Most importantly, the "new" > scheme should be built out from the existing framework. The > SELinux and RSBAC schemes are much more implementation models > than security policies. I'm not sure what you are trying to say here. The RSBAC and SELinux architectures already support Bell-LaPadula and Biba, and the set of example policy models provided with the two system include an example MLS/BLP model. I'm not sure what aspects of NT access control or No-SuperUser-Capabilities can't be handled via the existing architecture and interfaces of these two systems. It is precisely because SELinux and RSBAC provide general architectures (rather than just specific policies, although they do provide examples of those as well) that they are suitable for this purpose. > There are many issues associated with "security IDs", including > performance, exportability, and persistance. I favor keeping > real security attribute information to the indirection usually > required of security ID schemes. Mapping IDs to security data > is a major problem in application space. Of course, if IDs refer > to data with actually identifies the security information, > that's fine. My understanding is that that's not the case > for SELinux. In SELinux, security IDs are opaque handles to "security contexts", which contain the actual security attributes. The mapping is maintained by the security server, and is accessible (subject to control by the policy) to applications. With regard to persistence, we address that through persistent label mappings in each file system based on per-filesystem persistent security identifier number spaces. So security IDs are local and non-persistent (for scalability). In any event, this is all described at length in the SELinux documentation and the Flask paper. > You have always argued in the past that RSBAC is too > different from SELinux for their approaches to be useful > to SELinux. I recall in particular issues against the > wrapper approach. Either you are incorrectly remembering what I've said in the past, or I've previously spoken incorrectly. RSBAC isn't a wrapper-based approach. There is a lengthy thread on the selinux mailing list (see the archives) between Amon and I comparing SELinux and RSBAC. I think that both systems separate policy from enforcement and can support a variety of security policies. There are certain areas where each system has its advantages. > I do not believe that SELinux or RSBAC is a good starting point. > I believe that the first "module" should be Linux as it is today. > I believe that the second module should be "No Access Checks". > I believe that the third module should be Pure Posix Capabilities. > After that, anything goes to recommend extension to the mechanism. My concern is that this will not yield the truly generic solution desired by Linus. SELinux and RSBAC weren't created in a vacuum - they drew upon years of prior research. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Apr 19 2001 - 05:23:09 PDT