On Fri, 3 Aug 2001, richard offer wrote: > > - truly generic. No "MLS" vs "TE" vs "uid==0" vs "capability" at ALL. > > Something where the "uid == 0" version of security is just one case > > (which the embedded people might use), or where SELinux would be just a > > matter of loading the SELinux module and installing _that_ security > > model. Notice the scope of Linus' words. He didn't say anything about the kernel's DAC logic. He only referred to "uid==0" vs. "capability" vs. various nondiscretionary access control schemes (MLS, TE, etc). And LSM is moving the capability logic out into an optional module, so that you can choose to have ordinary superuser tests or capabilities or TE or MLS or combinations. > I don't think that the current solution really is "truly generic". It can't > support POSIX MAC, embedded systems or POSIX ACLs. And those are things we > know about today. If there are three known, there are likely to be more > unknown. "Truly generic" with respect to what? The current solution does conform to Linus' mandate. It does help embedded systems by moving (or at least starting to move) the capabilities out of the base kernel. It does allow the implementation of a variety of nondiscretionary access control schemes. > NFSv4 isn't even on the radar and yet it will be an big issue, probably > bigger than the others, since it will be implemented and deployed outside > of the traditional security community. NFSv4 seems clearly out of scope for LSM. -- 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 : Fri Aug 03 2001 - 09:27:30 PDT