On Thu, 6 Sep 2001, Chris Wright wrote: > i don't think this is enough. > > $ rgrep -r 'CAP_..._ADMIN' linux-2.4/drivers | wc -l > 296 > > so there are 296 instances of either CAP_NET_ADMIN or CAP_SYS_ADMIN > in the drivers. the only lsm hook i see in drivers in in char/tty_io.c > (which isn't colocated with a capable hook...this would be a problem > also). these are things like messing with NIC's, the entropy pool, > lvm opening character devices or block ioctls, raw device ioctls, etc... > > how is this not a problem for the capability override mechanism? I wasn't suggesting that the capable() hook should return success (0) for all capabilities. Just capabilities that are used to override DAC, so that the restrictive hook can become authoritative. Other capabilities, like CAP_NET_ADMIN or CAP_SYS_ADMIN, are often already authoritative (there is no other logic, just the capability test). Lachlan provided an example of a case where a capability is used both to override DAC and in an authoritative sense (CAP_SYS_ADMIN in msgget vs. CAP_SYS_ADMIN elsewhere). But that appears to be a questionable choice of capability anyway, since there is a comment suggesting the use of CAP_CHOWN and there is another capability that seems even more appropriate (CAP_IPC_OWNER). If CAP_SYS_ADMIN or CAP_NET_ADMIN are used interchangeably in a number of locations for both DAC override and authoritative control, then this obviously doesn't work. Is that what you are saying? -- 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 - 10:54:31 PDT