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/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:18 EST