Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Andreas Dilger <adilger@clusterfs.com>]

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/