On Wed, 5 Sep 2001, Chris Wright wrote: > * Lachlan McIlroy (lachlanat_private) wrote: > > There are some DAC checks that are coupled with capable > > calls that check for a capability other than > > CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH. For example, > > sys_setpriority uses CAP_SYS_NICE and sys_msgget uses > > CAP_SYS_ADMIN. If we make these capabilities permanently > > effective then we grant all processes access to system > > calls, such as sys_sethostname, that are normally > > restricted to processes that have these capabilities. > > ahh, this looks good. this gets back to the argument against > replacing all capable() hooks. we had considered this originally. > but after considering the > 500 capable() hooks all over the kernel > we decided that we'd use them and not replace them. especially > those in device drivers. > > so yes, i agree considering all the places where capable() calls > aren't followed by lsm hooks, you just gave away the house. this > is unacceptable. > > this looks like an, ahem, authoritative reason that we need to > support authoritative hooks. > > i trust i'll be corrected if i'm being blind. I don't see the argument for CAP_SYS_NICE - we have a hook after each call to capable(CAP_SYS_NICE), so universally granting CAP_SYS_NICE and then using the restrictive hook as an authoritative hook should work. The msgget example is a better one - we cannot universally grant CAP_SYS_ADMIN, since we do not always have a restrictive hook after each capable(CAP_SYS_ADMIN) call. But if you look at the comment in the msgget code, you'll see that they say that they could check for CAP_CHOWN instead, but don't. Actually, looking at capability.h, it seems like they should be using CAP_IPC_OWNER. IMHO, the problem here is that they are using the wrong capability in this case, something we could easily fix. I agree that there are a number of different capabilities used to override DAC restrictions, but this is documented in capability.h. So assuming we were to fix the above problem with msgget, where else is a single capability value used sometimes to override DAC and sometimes to authoritatively control an operation (where we lack a restrictive hook)? -- 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 Sep 06 2001 - 06:02:34 PDT