> -----Original Message----- > From: linux-security-module-adminat_private > [mailto:linux-security-module-adminat_private]On Behalf Of Stephen > Smalley > Sent: Thursday, September 06, 2001 11:01 PM > To: Chris Wright > Cc: linux-security-moduleat_private > Subject: Re: quotactl hook > > > > 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. I don't like the idea of using CAP_SYS_NICE to override a DAC check. If all DAC checks were coupled with capable checks for CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH then this would make a lot more sense and we would know that we are overriding all DAC checks (and only DAC checks). > > 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)? I'll keep looking... > > -- > 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 > --- Lachlan McIlroy Phone: +61 3 9596 4155 Trusted Linux Fax: +61 3 9596 2960 Adacel Technologies Ltd www.adacel.com _______________________________________________ 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 - 17:12:52 PDT