Stephen Smalley wrote: > Not exactly. The capable call doesn't have any object information, Ah, but it needs it, because ... > 1) The security module's capable hook function would always return > success for CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH. You are assuming that these capabilities are applied only to file system objects. They are also applied (or should be) to SysVIPC objects, sockets, and any other thingies with access control. You don't want DAC overridden on message queues just because you've got ACLs on file system objects. You also have to take into account that different file systems may have different access policies, with one using POSIX ACLs, one NFSv4 attributes, and a third with NT ACLs. Capable() has to have access to the object information to make these descriminations. An alternative is to have a seperate capability for every check in the system. This does not address the issue of per-filesystem semantics, and would result in Too Many capabilities. > I believe that this is functionally equivalent to making the permission > hook authoritative. ... , but it appears to > work just fine in this case, and this appears to be sufficient for POSIX > ACLs. Like I said, you Could do it. It's not as simple as you make it out to be because the U2X access control and privilege policies are more "sophisticated" than methinks they should be. -- Casey Schaufler Manager, Trust Technology, SGI caseyat_private voice: 650.933.1634 casey_pat_private Pager: 888.220.0607 _______________________________________________ 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 Nov 09 2001 - 09:08:28 PST