lkml.org 
[lkml]   [2003]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Extended Attributes for Security Modules against 2.5.68
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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.044 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site