Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley <sds@tycho.nsa.gov>]

On Thu, 2006-04-20 at 02:51 -0400, Kyle Moffett wrote:
> On Apr 19, 2006, at 02:56:28, Valdis.Kletnieks@vt.edu wrote:
> > On Wed, 19 Apr 2006 02:40:25 EDT, Kyle Moffett said:
> >> Perhaps the SELinux model should be extended to handle (dir-inode,  
> >> path-entry) pairs.  For example, if I want to protect the /etc/ 
> >> shadow file regardless of what tool is used to safely modify it, I  
> >> would set
> >
> > Some of us think that the tools can protect /etc/shadow just fine  
> > on their own, and are concerned with rogue software that abuses / 
> > etc/shadow without bothering to safely modify it..
> 
> Here I'm talking about using SELinux to protect /etc/shadow both  
> before _and_ after it's edited with vipw.  A tool like vipw does creat 
> () write() rename() to overwrite the /etc/shadow file, so any SELinux  
> system relying _only_ on inode is guaranteed to break.

To clarify:
- SELinux kernel access controls are configured by policy to ensure that
only approved tools can manipulate the file (based on inode attribute,
initially established at install time),
- SELinux kernel labeling mechanism for new inodes is configured by
policy to ensure that new files created by such tools are labeled with
the most restrictive label (i.e. the one for shadow, not passwd data) by
default, so that we don't leak information accidentally,
- Approved tools/libraries are instrumented to specify the desired label
for passwd vs. shadow (and backup files), since the same code re-creates
both on a transaction (at least when adding/removing users), so the
kernel can't make that distinction automatically; only the tool knows
that.  This is consistent with how DAC mode is handled for passwd vs.
shadow. 

No pathname-based mechanism in the kernel required, or desired.  Names
are meaningless to real security properties.

-- 
Stephen Smalley
National Security Agency

-
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/