Re: [RFC][PATCH] Extended Attributes for Security Modules

Re: [RFC][PATCH] Extended Attributes for Security Modules

[Stephen Smalley]

Andreas Gruenbacher wrote:
> Could you please try to priefly summarize the intended use of these
> security labels? Is this for MAC? Also it would be interesting to know
> what the required privileges would be to access the labels. There are
> probably some accesses that are allowed in the user's security context,
> and some others that are performed on behalf of a user process, but within
> the kernel's security context.
> 
> There may be some overlap with trusted extended attributes (see
> http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/man/man5/attr.5 for a
> manual page that contains a minimal description).

SELinux implements a flexible MAC architecture that can support many different 
kinds of MAC security models and includes Type Enforcement, Role-Based Access 
Control, and optionally Multi-Level Security in the example security server 
(policy engine).  It is not based on POSIX.1e MAC, and POSIX.1e MAC doesn't work 
so well for non-traditional MAC models like Type Enforcement and Role-Based 
Access Control.  We define a set of permissions that control the ability
of a user process to get and set the security label of a file, and the
kernel module internally performs get and set operations as appropriate 
when files are looked up and when new files are created.  We originally
implemented our own persistent label mapping using some meta-files, but
have reworked the SELinux implementation to use xattr if they are available,
as you can see in the patch on the NSA site.

However, SELinux is merely one of the possible security modules that
might be implemented via LSM, so we didn't want to limit this to just
SELinux.  It seems preferable to reserve a single index and attribute
name that can be used by any security module, and use the first few
bytes of the attribute value to indicate the particular security
module.  Most security modules seems to be implementing some form
of non-discretionary access control, but the LSM framework isn't specifically
limited to that.

The xattr_security.c code is actually derived from xattr_trusted.c, but I
thought that we should have a separate index and name for an attribute that
will be used by MAC schemes like SELinux.  Also, the xattr_security.c code 
differs from xattr_trusted.c in the following important respects:

1) We use a fixed attribute name (system.security) that is not
extensible.  Every security module would use that name for its
attributes (LSM only allows one security module at a time, and any
stacking has to be handled by the "principal" security module),
and would sanity check the value by checking the first few bytes
against some module identifier.  Using the "system" prefix seemed
appropriate given that this attribute is used internally by the security
module and not just by userspace.

2) Permission checking is handled via the security_inode_setxattr hook
in fs/xattr.c:setxattr, and updating of the inode's security field to
reflect changes to the attribute is handled by a new
security_inode_post_setxattr hook added by the patch.  The inode
semaphore ensures atomicity for the check and update (note that the down
is moved by the patch).  There is no permission check embedded in the
handler itself, since it will vary depending on the security module and
depending on whether the call is made from userspace or from the
security module itself.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [RFC][PATCH] Extended Attributes for Security Modules

[Andreas Gruenbacher]

Hello Stephen,

On 10 Apr 2003, Stephen Smalley wrote:

> Andreas Gruenbacher wrote:
> > Could you please try to priefly summarize the intended use of these
> > security labels? Is this for MAC? Also it would be interesting to know
> > what the required privileges would be to access the labels. There are
> > probably some accesses that are allowed in the user's security context,
> > and some others that are performed on behalf of a user process, but within
> > the kernel's security context.
> >
> > There may be some overlap with trusted extended attributes (see
> > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/man/man5/attr.5 for a
> > manual page that contains a minimal description).
>
> SELinux implements a flexible MAC architecture that can support many different
> kinds of MAC security models and includes Type Enforcement, Role-Based Access
> Control, and optionally Multi-Level Security in the example security server
> (policy engine).  It is not based on POSIX.1e MAC, and POSIX.1e MAC doesn't work
> so well for non-traditional MAC models like Type Enforcement and Role-Based
> Access Control.  We define a set of permissions that control the ability
> of a user process to get and set the security label of a file, and the
> kernel module internally performs get and set operations as appropriate
> when files are looked up and when new files are created.  We originally
> implemented our own persistent label mapping using some meta-files, but
> have reworked the SELinux implementation to use xattr if they are available,
> as you can see in the patch on the NSA site.
>
> However, SELinux is merely one of the possible security modules that
> might be implemented via LSM, so we didn't want to limit this to just
> SELinux.  It seems preferable to reserve a single index and attribute
> name that can be used by any security module, and use the first few
> bytes of the attribute value to indicate the particular security
> module.  Most security modules seems to be implementing some form
> of non-discretionary access control, but the LSM framework isn't specifically
> limited to that.
>
> The xattr_security.c code is actually derived from xattr_trusted.c, but I
> thought that we should have a separate index and name for an attribute that
> will be used by MAC schemes like SELinux.  Also, the xattr_security.c code
> differs from xattr_trusted.c in the following important respects:
>
> 1) We use a fixed attribute name (system.security) that is not
> extensible.  Every security module would use that name for its
> attributes (LSM only allows one security module at a time, and any
> stacking has to be handled by the "principal" security module),
> and would sanity check the value by checking the first few bytes
> against some module identifier.  Using the "system" prefix seemed
> appropriate given that this attribute is used internally by the security
> module and not just by userspace.

LSM only allows one principal security module at a time, but it allows to
switch between security modules. I am wondering what will happen if a user
switches between multiple security modules that label files. The new
module will see labels from the old module. It's a question of policy how
to deal with that case. Probably the policy restrictions the old module
was implementing should be considered invalid after another module was
used, and so the old labels should be ignored/removed.

Another case is stacked modules where more than one module needs file
labels. Your proposed API does not support that. I would rather use
individual attribute names for each module (e.g., "security.selinux",
etc.).

The design of filesystem EAs differentiates rough access policies by
attribute namespace ("system.*", "user.*", "trusted.*"). The system
namespace is special in that each "system.*" attribute may have different
access restrictions. Attributes in the "user.*" namespace are subject to
the same restrictions as the contents of the file the attributes are
attached to. Attributes in the "trusted.*" namespace are accessible only
to users capable of CAP_SYS_ADMIN.

The "security" namespace/attribute you are proposing is quite similar to
the "trusted.*" namespace, except that CAP_SYS_ADMIN does not grant any
rights there. It is unlikely that security modules will/can remove the
powers of the CAP_SYS_ADMIN capability; many areas in the kernel depend on
it. I would expect that these modules make sure that no process will be
able to attain that capability in the first place. In that light, wouldn't
it be possible to use the "trusted.*" namespace for storing LSM file
labels instead (e.g., "trusted.selinux")? There's nothing wrong with
introducing another namespace if necessary, but we might be able to avoid
that.


Cheers,
Andreas.

Re: [RFC][PATCH] Extended Attributes for Security Modules

[Stephen Smalley]

On Sun, 2003-04-13 at 18:57, Andreas Gruenbacher wrote:
> LSM only allows one principal security module at a time, but it allows to
> switch between security modules. I am wondering what will happen if a user
> switches between multiple security modules that label files. The new
> module will see labels from the old module. It's a question of policy how
> to deal with that case. Probably the policy restrictions the old module
> was implementing should be considered invalid after another module was
> used, and so the old labels should be ignored/removed.

Thanks for your reply.  However, I don't see the above scenario as
compelling.  I would expect most real security "modules" to be built
into the kernel or inserted at a very early point during initialization
and _never_ removed.  Dynamic switching among multiple security modules
that use the extended attributes seems even less likely.  The typical
"switching" that occurs in LSM is simply the transition from the dummy
module to the real security module when the real security module
initializes, and this poses no problem for xattr.

> Another case is stacked modules where more than one module needs file
> labels. Your proposed API does not support that. I would rather use
> individual attribute names for each module (e.g., "security.selinux",
> etc.).

Note that LSM intentionally does not provide any mechanism itself for
sharing the security fields of the kernel data structures.  Stacking has
to be handled by the principal security module.  In practice, I would
expect that any "stacking" of multiple security modules that use
security fields and xattr will actually involve creation of a new module
that integrates the logic of the individual modules.  This is preferable
anyway to ensure that the interactions among the security modules are
well understood, that the logic is combined in a sensible manner, and
that the individual logics can not subvert one another.  Given this
view, using an individual attribute name for each module would seem to
serve no purpose.  An integrated module that combines logic of several
modules can store all of the necessary security data as a single
attribute value.  Note that SELinux already does this for the set of
security models implemented by its policy engine.

> The design of filesystem EAs differentiates rough access policies by
> attribute namespace ("system.*", "user.*", "trusted.*"). The system
> namespace is special in that each "system.*" attribute may have different
> access restrictions. Attributes in the "user.*" namespace are subject to
> the same restrictions as the contents of the file the attributes are
> attached to. Attributes in the "trusted.*" namespace are accessible only
> to users capable of CAP_SYS_ADMIN.
> 
> The "security" namespace/attribute you are proposing is quite similar to
> the "trusted.*" namespace, except that CAP_SYS_ADMIN does not grant any
> rights there. It is unlikely that security modules will/can remove the
> powers of the CAP_SYS_ADMIN capability; many areas in the kernel depend on
> it. I would expect that these modules make sure that no process will be
> able to attain that capability in the first place. In that light, wouldn't
> it be possible to use the "trusted.*" namespace for storing LSM file
> labels instead (e.g., "trusted.selinux")? There's nothing wrong with
> introducing another namespace if necessary, but we might be able to avoid
> that.

SELinux defines its own set of permission checks for getxattr and
setxattr that are implemented via the security_inode_getxattr and
security_inode_setxattr hooks in the getxattr and setxattr calls.  These
permission checks are performed between the process security context and
the relevant file security contexts (in the case of setxattr, we check
permissions to the existing file security context and to the new file
security context).  The CAP_SYS_ADMIN check isn't suitable at all; it is
more restrictive than we would like for getxattr (e.g. ordinary users
seeing security labels on their files via a patched ls) and more
coarse-grained than we would like for setxattr (e.g. letting an
application that manages multiple types of security data transition one
type to another while still preventing it from arbitrary relabels). 
Since it is implemented in the xattr handler, the CAP_SYS_ADMIN check
would be applied both to operations invoked from userspace and from the
security module, which is undesirable.  CAP_SYS_ADMIN will still need to
be granted to some processes with administrative function at least until
all such operations are covered by finer-grained security hooks or
finer-grained capabilities.   Granting it to processes that merely want
to perform getxattr or setxattr would pose a definite risk. 
Consequently, I think that a separate attribute is necessary.  Thanks
again for your reply.
 
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [RFC][PATCH] Extended Attributes for Security Modules

[richard offer]

* frm sds@epoch.ncsc.mil "04/15/03 09:41:48 -0400" | sed '1,$s/^/* /'
*
* 
* Note that LSM intentionally does not provide any mechanism itself for
* sharing the security fields of the kernel data structures.  Stacking has
* to be handled by the principal security module.  

I see modules as empheral, but attritbutes as permanant. If I'm running one
LSM module, I reboot and use a different LSM module, what happens to the
attributes that the first module added to the file ?

Either we should guarantee that modules only touch attributes they know
about---ignoring all others (but not overwriting them), or we have separate
namespaces for each module's attributes.

Stacking modules will work with either scheme, but its seems to be that
switching policies over a reboot could easily be broken by a scheme that
shared a single namespace.
 
* -- 
* Stephen Smalley <sds@epoch.ncsc.mil>
* National Security Agency

richard.

-- 
-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

Re: [RFC][PATCH] Extended Attributes for Security Modules

[Stephen Smalley]

On Tue, 2003-04-15 at 12:58, richard offer wrote:
> I see modules as empheral, but attritbutes as permanant. If I'm running one
> LSM module, I reboot and use a different LSM module, what happens to the
> attributes that the first module added to the file ?

I'm not going to switch between a SELinux "module" and a non-SELinux
"module" or vice versa without relabeling the filesystem to an
appropriate initial state of security labels that is meaningful to the
"module" I want to use.  I also wouldn't be performing such switching at
all on any real systems.

> Either we should guarantee that modules only touch attributes they know
> about---ignoring all others (but not overwriting them), or we have separate
> namespaces for each module's attributes.

A security module can sanity check the first few bytes of the attribute
value if it desires, and handle a mismatch as it desires.  That is a
policy issue and up to the module writer.

You also need to consider the implications for userspace of using a
separate attribute name for each security module.  Do you really want to
maintain your own patches for all of the utilities to let users get and
set file security labels using your attribute name?  Note that we can
add or remove security attributes to/from the SELinux security context
without requiring changes to our patches for the utilities; the utility
patches don't have to be tied to a specific security model.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [RFC][PATCH] Extended Attributes for Security Modules

[Stephen Smalley]

On Tue, 2003-04-15 at 12:58, richard offer wrote:
> I see modules as empheral, but attritbutes as permanant. If I'm running one
> LSM module, I reboot and use a different LSM module, what happens to the
> attributes that the first module added to the file ?
> 
> Either we should guarantee that modules only touch attributes they know
> about---ignoring all others (but not overwriting them), or we have separate
> namespaces for each module's attributes.
> 
> Stacking modules will work with either scheme, but its seems to be that
> switching policies over a reboot could easily be broken by a scheme that
> shared a single namespace.

Thanks for your comments.  It occurred to me after I sent my initial
reply that you might be thinking of a scenario where you have two
different security modules for two different environments, and you
switch back and forth between them depending on what environment you are
working in.  However, I think that this scenario is fundamentally
flawed, as the two modules will end up needing to be tightly coupled in
order to provide any continuous guarantees of security and would be
better implemented as a single module that understands two (or n) states
of operation and has a mechanism for secure transitions between those
states.  If you keep them as independent modules, then each module has
no way of knowing what kind of data mixing occurred while the other
module was active, so the old attributes of existing files are no longer
trustworthy, and each module has no way of knowing how to handle new
files that were created while the other module was active.  You really
need the two modules to be aware of each other and to maintain
sufficient state information so that the other module can recover to a
secure initial state, at which point you might as well merge them into
one module with multiple states of operation.  A single module with
multiple states of operation can also potentially support transitions on
events without a reboot (or the overhead of a full module
removal+insertion), so you have greater flexibility.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [RFC][PATCH] Extended Attributes for Security Modules

[richard offer]

* frm sds@epoch.ncsc.mil "04/16/03 09:47:22 -0400" | sed '1,$s/^/* /'
* 
* Thanks for your comments.  It occurred to me after I sent my initial
* reply that you might be thinking of a scenario where you have two
* different security modules for two different environments, and you
* switch back and forth between them depending on what environment you are
* working in.  

I'm not sure what I was thinking, I think I was thinking about smaller
modules, say capabilities and openwall or alternatively a reluctance to
remove things that "belong" to other people... 

If you attach a capability attribibute to a file under the capability
module, what happens when you use SELinux ? Under your scheme, you'd remove
the capability and write a combined attribute that included SELinux and and
if needed the capability. 

Under my scheme, the capability attribute would be left alone, SELinux
would add its own, and then as its the primary module would decide whether
to use the existing capability attribute or its own "combined" attribute.
The important thing is that if you ever decide to reboot a pure capability
system that you don't have to refigure all your attributes (although you
could/should).

Extended attributes are still relatively rare that people forget to record
them when replacing a file (I do that all the time under Trusted Irix),
under your scheme they would have to record every attribute on the system
before loading a module if they every wanted to return to its prior state.
If you forgot to do it just once the consequences could be nasty.

With separate attributes, its easy to write a tool to "de-dte" a system by
removing all the DTE attributes and know that nothing else will change. But
that would be a direct user action, not an unforseen side effect.

I can see your reasons for the single attribute (known quantity for
production systems), but think its better at this stage to experiment with
multiple attributes and see how people use them before forcing everyone to
a single standard. It allows small steps rather than force everyone to make
a single large one.

* Stephen Smalley <sds@epoch.ncsc.mil>
* National Security Agency

richard.

-- 
-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

Re: [RFC][PATCH] Extended Attributes for Security Modules

[Stephen Smalley]

On Wed, 2003-04-16 at 18:02, richard offer wrote:
> If you attach a capability attribibute to a file under the capability
> module, what happens when you use SELinux ? Under your scheme, you'd remove
> the capability and write a combined attribute that included SELinux and and
> if needed the capability. 

Yes.  You have to initially label the filesystem in order to use
SELinux, as you would with any MAC scheme, and incorporating additional
state into that labeling procedure wouldn't be difficult.  It isn't
clear that you actually need the additional state; you can assign
privileges via TE rather than using capabilities if you want
fine-grained decomposition of root.

However, point taken - if the existing Linux capability model (in the
mainline kernel) was already using xattr and had an attribute name
reserved, I don't think we would have suggested re-using that attribute
name (or its handler) for all security modules.  I view this as a
special case, as the capability model was already in mainline and is
expected to exist by certain applications, so colliding with it could
pose a problem for many security modules.  For other security modules,
or at the very least, the class of security modules implementing a MAC
scheme, I would still suggest a single attribute name and handler.  

> Under my scheme, the capability attribute would be left alone, SELinux
> would add its own, and then as its the primary module would decide whether
> to use the existing capability attribute or its own "combined" attribute.
> The important thing is that if you ever decide to reboot a pure capability
> system that you don't have to refigure all your attributes (although you
> could/should).

True.  As above, I view this as a special case for the capability model
because it has been part of the mainline.  If I am switching between
different MAC schemes, I need to do a thorough relabeling of the
filesystem, and that relabeling is a delicate operation as one MAC
scheme may permit data mixing that is prohibited by another, leading to
a violation of confidentiality or integrity requirements of the other
MAC scheme.  Also, note that if you switch from a MAC scheme to a
capability-only scheme, switching back is a very delicate operation if
you want to verify a secure state.

> Extended attributes are still relatively rare that people forget to record
> them when replacing a file (I do that all the time under Trusted Irix),
> under your scheme they would have to record every attribute on the system
> before loading a module if they every wanted to return to its prior state.
> If you forgot to do it just once the consequences could be nasty.

Since you have to initially relabel the filesystem to switch to a
different MAC scheme, it isn't unreasonable to have that labeling step
also make a backup of any existing attribute values prior to changing
them.

> I can see your reasons for the single attribute (known quantity for
> production systems), but think its better at this stage to experiment with
> multiple attributes and see how people use them before forcing everyone to
> a single standard. It allows small steps rather than force everyone to make
> a single large one.

Per-module attribute names create no incentive for the security module
writers to provide a consistent API and guarantees a forked userland. 

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [RFC][PATCH] Extended Attributes for Security Modules

[Chris Wright]

* Stephen Smalley (sds@epoch.ncsc.mil) wrote:
> On Wed, 2003-04-16 at 18:02, richard offer wrote:
> > I can see your reasons for the single attribute (known quantity for
> > production systems), but think its better at this stage to experiment with
> > multiple attributes and see how people use them before forcing everyone to
> > a single standard. It allows small steps rather than force everyone to make
> > a single large one.
> 
> Per-module attribute names create no incentive for the security module
> writers to provide a consistent API and guarantees a forked userland. 

This is the core issue.  Personally, I'd rather stick to simple strings
and per-module attributes rooted at a common point.  This is simplest
for userspace tools.  But the attribute namespace is effectively flat,
so it's a question of simplicity for locating the attributes.  A simple
getxattr(2) vs. a listxattr(2) plus multiple getxattr(2).  Unfortunately,
this points at a single standard name I think...

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [RFC][PATCH] Extended Attributes for Security Modules

[richard offer]

* frm chris@wirex.com "04/17/03 13:30:59 -0700" | sed '1,$s/^/* /'
*
** Stephen Smalley (sds@epoch.ncsc.mil) wrote:
*> On Wed, 2003-04-16 at 18:02, richard offer wrote:
*> > I can see your reasons for the single attribute (known quantity for
*> > production systems), but think its better at this stage to experiment
*> > with multiple attributes and see how people use them before forcing
*> > everyone to a single standard. It allows small steps rather than force
*> > everyone to make a single large one.
*> 
*> Per-module attribute names create no incentive for the security module
*> writers to provide a consistent API and guarantees a forked userland. 
* 
* This is the core issue.  Personally, I'd rather stick to simple strings
* and per-module attributes rooted at a common point.  This is simplest
* for userspace tools.  But the attribute namespace is effectively flat,
* so it's a question of simplicity for locating the attributes.  A simple
* getxattr(2) vs. a listxattr(2) plus multiple getxattr(2).  Unfortunately,
* this points at a single standard name I think...

Good point. Okay you've conviced me enough that while I don't agree more
than 51%, I'm at least going to shut up until the next time.


Would it make sense to have a single "backup/restore security label" tool
that is distributed alongside LSM rather than relying on each module writer
developing their own.

* 
* thanks,
* -chris

richard.

-- 
-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

Re: [RFC][PATCH] Extended Attributes for Security Modules

[Chris Wright]

* richard offer (offer@sgi.com) wrote:
> * frm chris@wirex.com "04/17/03 13:30:59 -0700" | sed '1,$s/^/* /'
> * 
> * This is the core issue.  Personally, I'd rather stick to simple strings
> * and per-module attributes rooted at a common point.  This is simplest
> * for userspace tools.  But the attribute namespace is effectively flat,
> * so it's a question of simplicity for locating the attributes.  A simple
> * getxattr(2) vs. a listxattr(2) plus multiple getxattr(2).  Unfortunately,
> * this points at a single standard name I think...
> 
> Good point. Okay you've conviced me enough that while I don't agree more
> than 51%, I'm at least going to shut up until the next time.

Heh, it's a valid question.  I like per-module attributes, but I don't
think they are as nice for userland tools.  I don't acutally like
encoding namesapce into the attribute value, but I'm not sure the
alternative is much different/better.

> Would it make sense to have a single "backup/restore security label" tool
> that is distributed alongside LSM rather than relying on each module writer
> developing their own.

You mean to ensure that labels are accumulated rather than replaced?
Could be useful I suppose.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [RFC][PATCH] Extended Attributes for Security Modules

[Chuck Ebbert]

Stephen Smalley wrote:


> In practice, I would
> expect that any "stacking" of multiple security modules that use
> security fields and xattr will actually involve creation of a new module
> that integrates the logic of the individual modules.  This is preferable
> anyway to ensure that the interactions among the security modules are
> well understood, that the logic is combined in a sensible manner, and
> that the individual logics can not subvert one another.


  On FreeBSD 5 you 'stack' the mac_biba and mac_mls modules to get both
integrity and confidentiality, right?  Or is that something different?

--
 Chuck

Re: [RFC][PATCH] Extended Attributes for Security Modules

[Chris Wright]

* Chuck Ebbert (76306.1226@compuserve.com) wrote:
> Stephen Smalley wrote:
> 
> > In practice, I would
> > expect that any "stacking" of multiple security modules that use
> > security fields and xattr will actually involve creation of a new module
> > that integrates the logic of the individual modules.  This is preferable
> > anyway to ensure that the interactions among the security modules are
> > well understood, that the logic is combined in a sensible manner, and
> > that the individual logics can not subvert one another.
> 
>   On FreeBSD 5 you 'stack' the mac_biba and mac_mls modules to get both
> integrity and confidentiality, right?  Or is that something different?

It's a difference in implementation.  FreeBSD builds stacking directly into
the framework, whereas LSM makes stacking a policy decision for the module.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

[RFC][PATCH] Extended Attributes for Security Modules

[Stephen Smalley]

As part of preparing SELinux for submission to mainline 2.5, the SELinux
API is being reworked based on earlier discussions (starting when
sys_security was removed from 2.5).  As a preliminary step toward
submitting SELinux, I'd like to request comments on an extended
attribute handler for security modules.  This message includes a patch
against 2.5.67 (also available from 
http://www.nsa.gov/selinux/lk/A02xattr.patch.gz) that implements the changes 
to the base kernel and the LSM framework to support the use of extended 
attributes by security modules.  You can obtain a full SELinux patch against 
2.5.67 that includes these changes along with the SELinux code that uses them 
from http://www.nsa.gov/selinux/lk/2.5.67-selinux1.patch.gz, and some
relevant userland components from
http://www.nsa.gov/selinux/lk/selinux-2.5.tgz.  Note that the full
SELinux patch also contains some other changes to the base kernel and
the LSM framework that will be submitted as separate RFCs.

The patch below implements an extended attribute handler for ext3 (as an
initial example, not as an intended limitation) for a system.security
attribute that can be used by a security module and by security-aware
applications to get and set file security labels.  The patch also
adjusts the LSM hook in setxattr and adds a post_setxattr hook so that
the security module can update the inode security field upon a
successful change to the file security label and can ensure atomicity
for the security check and the update to the inode security field.

I should note that we will ultimately need such xattr handlers not only
for conventional filesystems such as ext3 but also for pseudo
filesystems such as devpts, e.g. so that sshd can set the security label
properly on the pty that will be used for a user session.  The SELinux
release includes a patched sshd program that does this using the old
SELinux API for setting file security labels, but this will need to be
migrated to using setxattr if we are going to use the xattr API for all
of our file labeling operations.

Index: linux-2.5/fs/Kconfig
diff -u linux-2.5/fs/Kconfig:1.1.1.3 linux-2.5/fs/Kconfig:1.2
--- linux-2.5/fs/Kconfig:1.1.1.3	Tue Mar 25 09:36:05 2003
+++ linux-2.5/fs/Kconfig	Wed Mar 26 14:03:25 2003
@@ -131,6 +131,18 @@
 
 	  If you don't know what Access Control Lists are, say N
 
+config EXT3_FS_SECURITY
+	bool "Ext3 Security Labels"
+	depends on EXT3_FS_XATTR
+	help
+	  Security labels support alternative access control models
+	  implemented by security modules like SELinux.  This option
+	  enables an extended attribute handler for file security
+	  labels in the ext3 filesystem.
+
+	  If you are not using a security module that requires using
+	  extended attributes for file security labels, say N.
+
 config JBD
 # CONFIG_JBD could be its own option (even modular), but until there are
 # other users than ext3, we will simply make it be the same as CONFIG_EXT3_FS
Index: linux-2.5/fs/xattr.c
diff -u linux-2.5/fs/xattr.c:1.1.1.1 linux-2.5/fs/xattr.c:1.4
--- linux-2.5/fs/xattr.c:1.1.1.1	Wed Mar 12 10:55:12 2003
+++ linux-2.5/fs/xattr.c	Wed Mar 26 14:03:25 2003
@@ -79,15 +79,16 @@
 
 	error = -EOPNOTSUPP;
 	if (d->d_inode->i_op && d->d_inode->i_op->setxattr) {
+		down(&d->d_inode->i_sem);
 		error = security_inode_setxattr(d, kname, kvalue, size, flags);
 		if (error)
 			goto out;
-		down(&d->d_inode->i_sem);
 		error = d->d_inode->i_op->setxattr(d, kname, kvalue, size, flags);
+		if (!error)
+			security_inode_post_setxattr(d, kname, kvalue, size, flags);
+out:
 		up(&d->d_inode->i_sem);
 	}
-
-out:
 	xattr_free(kvalue, size);
 	return error;
 }
Index: linux-2.5/fs/ext3/Makefile
diff -u linux-2.5/fs/ext3/Makefile:1.1.1.1 linux-2.5/fs/ext3/Makefile:1.2
--- linux-2.5/fs/ext3/Makefile:1.1.1.1	Wed Mar 12 10:55:31 2003
+++ linux-2.5/fs/ext3/Makefile	Wed Mar 26 14:03:26 2003
@@ -14,3 +14,7 @@
 ifeq ($(CONFIG_EXT3_FS_POSIX_ACL),y)
 ext3-objs += acl.o
 endif
+
+ifeq ($(CONFIG_EXT3_FS_SECURITY),y)
+ext3-objs += xattr_security.o
+endif
Index: linux-2.5/fs/ext3/xattr.c
diff -u linux-2.5/fs/ext3/xattr.c:1.1.1.3 linux-2.5/fs/ext3/xattr.c:1.2
--- linux-2.5/fs/ext3/xattr.c:1.1.1.3	Tue Mar 25 09:37:19 2003
+++ linux-2.5/fs/ext3/xattr.c	Wed Mar 26 14:03:26 2003
@@ -1141,22 +1141,33 @@
 				  &ext3_xattr_trusted_handler);
 	if (err)
 		goto out;
+#ifdef CONFIG_EXT3_FS_SECURITY
+	err = ext3_xattr_register(EXT3_XATTR_INDEX_SECURITY,
+				  &ext3_xattr_security_handler);
+	if (err)
+		goto out1;
+#endif
 #ifdef CONFIG_EXT3_FS_POSIX_ACL
 	err = init_ext3_acl();
 	if (err)
-		goto out1;
+		goto out2;
 #endif
 	ext3_xattr_cache = mb_cache_create("ext3_xattr", NULL,
 		sizeof(struct mb_cache_entry) +
 		sizeof(struct mb_cache_entry_index), 1, 6);
 	if (!ext3_xattr_cache) {
 		err = -ENOMEM;
-		goto out2;
+		goto out3;
 	}
 	return 0;
-out2:
+out3:
 #ifdef CONFIG_EXT3_FS_POSIX_ACL
 	exit_ext3_acl();
+out2:
+#endif
+#ifdef CONFIG_EXT3_FS_SECURITY
+	ext3_xattr_unregister(EXT3_XATTR_INDEX_SECURITY,
+			      &ext3_xattr_security_handler);
 out1:
 #endif
 	ext3_xattr_unregister(EXT3_XATTR_INDEX_TRUSTED,
@@ -1175,6 +1186,10 @@
 	ext3_xattr_cache = NULL;
 #ifdef CONFIG_EXT3_FS_POSIX_ACL
 	exit_ext3_acl();
+#endif
+#ifdef CONFIG_EXT3_FS_SECURITY
+	ext3_xattr_unregister(EXT3_XATTR_INDEX_SECURITY,
+			      &ext3_xattr_security_handler);
 #endif
 	ext3_xattr_unregister(EXT3_XATTR_INDEX_TRUSTED,
 			      &ext3_xattr_trusted_handler);
Index: linux-2.5/fs/ext3/xattr.h
diff -u linux-2.5/fs/ext3/xattr.h:1.1.1.1 linux-2.5/fs/ext3/xattr.h:1.2
--- linux-2.5/fs/ext3/xattr.h:1.1.1.1	Wed Mar 12 10:55:32 2003
+++ linux-2.5/fs/ext3/xattr.h	Wed Mar 26 14:03:26 2003
@@ -21,6 +21,7 @@
 #define EXT3_XATTR_INDEX_POSIX_ACL_ACCESS	2
 #define EXT3_XATTR_INDEX_POSIX_ACL_DEFAULT	3
 #define EXT3_XATTR_INDEX_TRUSTED		4
+#define EXT3_XATTR_INDEX_SECURITY	        5
 
 struct ext3_xattr_header {
 	__u32	h_magic;	/* magic number for identification */
@@ -141,3 +142,4 @@
 
 extern struct ext3_xattr_handler ext3_xattr_user_handler;
 extern struct ext3_xattr_handler ext3_xattr_trusted_handler;
+extern struct ext3_xattr_handler ext3_xattr_security_handler;
Index: linux-2.5/fs/ext3/xattr_security.c
diff -u /dev/null linux-2.5/fs/ext3/xattr_security.c:1.1
--- /dev/null	Tue Apr  8 11:33:34 2003
+++ linux-2.5/fs/ext3/xattr_security.c	Wed Mar 26 14:03:26 2003
@@ -0,0 +1,52 @@
+/*
+ * linux/fs/ext3/xattr_security.c
+ * Handler for storing security labels as extended attributes.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/fs.h>
+#include <linux/smp_lock.h>
+#include <linux/ext3_jbd.h>
+#include <linux/ext3_fs.h>
+#include "xattr.h"
+
+#define XATTR_NAME_SECURITY "system.security"
+
+static size_t
+ext3_xattr_security_list(char *list, struct inode *inode,
+		    const char *name, int name_len)
+{
+	const int size = sizeof(XATTR_NAME_SECURITY);
+
+	if (list) 
+		memcpy(list, XATTR_NAME_SECURITY, size);
+	return size;
+}
+
+static int
+ext3_xattr_security_get(struct inode *inode, const char *name,
+		       void *buffer, size_t size)
+{
+	if (strcmp(name, "") != 0)
+		return -EINVAL;
+	return ext3_xattr_get(inode, EXT3_XATTR_INDEX_SECURITY, name,
+			      buffer, size);
+}
+
+static int
+ext3_xattr_security_set(struct inode *inode, const char *name,
+		       const void *value, size_t size, int flags)
+{
+	if (strcmp(name, "") != 0)
+		return -EINVAL;
+	return ext3_xattr_set(inode, EXT3_XATTR_INDEX_SECURITY, name,
+			      value, size, flags);
+}
+
+struct ext3_xattr_handler ext3_xattr_security_handler = {
+	.prefix	= XATTR_NAME_SECURITY,
+	.list	= ext3_xattr_security_list,
+	.get	= ext3_xattr_security_get,
+	.set	= ext3_xattr_security_set,
+};
Index: linux-2.5/include/linux/security.h
diff -u linux-2.5/include/linux/security.h:1.1.1.2 linux-2.5/include/linux/security.h:1.13
--- linux-2.5/include/linux/security.h:1.1.1.2	Wed Mar 19 09:54:58 2003
+++ linux-2.5/include/linux/security.h	Tue Apr  1 15:27:53 2003
@@ -361,6 +361,9 @@
  * 	Check permission before setting the extended attributes
  * 	@value identified by @name for @dentry.
  * 	Return 0 if permission is granted.
+ * @inode_post_setxattr:
+ * 	Update inode security field after successful setxattr operation.
+ * 	@value identified by @name for @dentry.
  * @inode_getxattr:
  * 	Check permission before obtaining the extended attributes
  * 	identified by @name for @dentry.
@@ -1036,6 +1039,8 @@
         void (*inode_delete) (struct inode *inode);
 	int (*inode_setxattr) (struct dentry *dentry, char *name, void *value,
 			       size_t size, int flags);
+	void (*inode_post_setxattr) (struct dentry *dentry, char *name, void *value,
+				     size_t size, int flags);
 	int (*inode_getxattr) (struct dentry *dentry, char *name);
 	int (*inode_listxattr) (struct dentry *dentry);
 	int (*inode_removexattr) (struct dentry *dentry, char *name);
@@ -1464,6 +1472,12 @@
 	return security_ops->inode_setxattr (dentry, name, value, size, flags);
 }
 
+static inline void security_inode_post_setxattr (struct dentry *dentry, char *name,
+						void *value, size_t size, int flags)
+{
+	security_ops->inode_post_setxattr (dentry, name, value, size, flags);
+}
+
 static inline int security_inode_getxattr (struct dentry *dentry, char *name)
 {
 	return security_ops->inode_getxattr (dentry, name);
@@ -2063,6 +2087,10 @@
 	return 0;
 }
 
+static inline void security_inode_post_setxattr (struct dentry *dentry, char *name,
+						 void *value, size_t size, int flags)
+{ }
+
 static inline int security_inode_getxattr (struct dentry *dentry, char *name)
 {
 	return 0;
Index: linux-2.5/security/dummy.c
diff -u linux-2.5/security/dummy.c:1.1.1.2 linux-2.5/security/dummy.c:1.11
--- linux-2.5/security/dummy.c:1.1.1.2	Wed Mar 19 09:59:17 2003
+++ linux-2.5/security/dummy.c	Mon Mar 31 16:37:37 2003
@@ -334,6 +334,11 @@
 	return 0;
 }
 
+static void dummy_inode_post_setxattr (struct dentry *dentry, char *name, void *value,
+				       size_t size, int flags)
+{
+}
+
 static int dummy_inode_getxattr (struct dentry *dentry, char *name)
 {
 	return 0;
@@ -803,6 +818,7 @@
 	set_to_dummy_if_null(ops, inode_getattr);
 	set_to_dummy_if_null(ops, inode_delete);
 	set_to_dummy_if_null(ops, inode_setxattr);
+	set_to_dummy_if_null(ops, inode_post_setxattr);
 	set_to_dummy_if_null(ops, inode_getxattr);
 	set_to_dummy_if_null(ops, inode_listxattr);
 	set_to_dummy_if_null(ops, inode_removexattr);