On Apr 24, 2003 15:02 -0400, Stephen Smalley wrote: > I don't think that would help. As I mentioned during the earlier > discussion with Andreas, you want to be able to allow the security > module to call the inode getxattr and setxattr operations without > restriction for internal management of the security labels, while > applying access controls to user processes invoking the [gs]etxattr > system calls. Hence, you don't want the permission check implemented in > the handler; it is better to handle the checking entirely via the LSM > hooks in the [gs]etxattr calls and allow unrestricted internal use of > the inode [gs]etxattr operations by the module. Capability checks are > also too coarse-grained; you want to be able to perform a permission > check based on the process and the inode attributes, not just a > process-based check. > > If the intent of the trusted namespace is for attributes that can be > managed by superuser processes (this is my impression), then I think it > would be better to create a separate namespace and handler for security > modules for clarity. Or at least for MAC modules. Wasn't part of the LSM setup done in a way that there would be "default" handlers for the hooks for normal PID/capability checking in the absence of another LSM module? I thought that was one of the reasons LSM hooks were accepted into the kernel, since this would allow even the default file/process permission checks to be compiled out for, say, embedded systems that only run as root anyways. Couldn't that be used to do the trusted-namespace- means-CAP_SYS_ADMIN checks, but it can be replaced by other LSM security modules if desired? Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ _______________________________________________ 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 Apr 24 2003 - 12:42:41 PDT