Messages in this thread | | | Subject | Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks | From | Stephen Smalley <> | Date | Thu, 20 Apr 2006 08:40:03 -0400 |
| |
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/
| |