On Thu, 31 May 2001, Crispin Cowan wrote: > Another option we discussed in a meeting this afternoon was "kick capabilities > out". All of the security modules we (WireX) understand are "restrictive", > and only capabilities is "permissive". If we kick capabilities out of the > picture, LSM gets simpler. I think the problem is that we are thinking of capabilities as a standalone module rather than as a replacement for the superuser logic that in turn is merely a portion of the overall base Linux access control logic. Being able to decompose the superuser is a very useful ability. In prior prototypes (e.g. DTOS), we've decomposed the superuser using Type Enforcement (TE) into multiple domains, and we would like to be able to do the same thing in Linux. In fact, I would think that the Linux kernel developers would be favorable to the notion of being able to decompose the superuser into multiple roles/domains. If you move all of the Linux access control logic into the hook functions (option #2), then capabilities or TE overrides simply become part of the internal module logic. If you take option #3, then the module is free to implement capabilities or TE overrides if it wants. Also, it should be noted that some capabilities are used to control the use of privileged operations, while other capabilities are used to override DAC restrictions. So capabilities are not always "permissive". > "Kick capabilities out" also comes in two flavors. One is to leave it in the > kernel, rather than make it an LSM module. The other is to kick it right out > of Linux, because the POSIX standard has failed, support for Capabilities in > Linux is lame, and we think it sucks anyway :-) As with some other options, > this may be a hard sell. But I think it deserves serious consideration. I'm all for leaving the existing capable() calls alone, and merely inserting one of our hooks into the capable() function to allow the module to implement additional logic on capability checks (in addition to inserting new hooks wherever we need them, including some overlap with the capable() calls in cases where we need more parameters). But I think that we do need to move the rest of the capability logic out of the base kernel (e.g. the guts of the capable() function, the processing in execve, the processing in the capability-related system calls) based on Linus' message that sparked this effort. People can then choose whether they want a real capabilities module or if they just want the traditional superuser logic or if they want to use Role-Based Access Control or Type Enforcement to decompose root instead (the latter being my own preference). It isn't really fair to bash the capabilities implementation based on what is in the current kernel, since it lacks support in the file system. I think the Linux-Privs people have an implementation that does provide such support. -- 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 Jun 01 2001 - 06:35:11 PDT