Messages in this thread | | | Date | Tue, 7 Aug 2007 09:11:49 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [PATCH 1/1] file capabilities: clear fcaps on inode change (v2) |
| |
Quoting Stephen Smalley (sds@tycho.nsa.gov): > On Mon, 2007-08-06 at 13:52 -0500, Serge E. Hallyn wrote: > > >From 1376764cbb54243f088cf00c39000c4f4418f461 Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <serue@us.ibm.com> > > Date: Mon, 6 Aug 2007 14:20:06 -0400 > > Subject: [PATCH 1/1] file capabilities: clear fcaps on inode change (v2) > > > > When a file with posix capabilities is overwritten, the > > file capabilities, like a setuid bit, should be removed. > > > > This patch introduces security_inode_killpriv(). This is > > currently only defined for capability, and is called when > > an inode is changed to inform the security module that > > it may want to clear out any privilege attached to that inode. > > The capability module checks whether any file capabilities > > are defined for the inode, and, if so, clears them. > > > > Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> > > --- > > fs/attr.c | 7 +++++++ > > fs/nfsd/vfs.c | 4 ++-- > > fs/open.c | 3 ++- > > fs/splice.c | 4 ++++ > > include/linux/fs.h | 1 + > > include/linux/security.h | 18 ++++++++++++++++++ > > mm/filemap.c | 5 +++++ > > security/capability.c | 1 + > > security/commoncap.c | 27 +++++++++++++++++++++++++++ > > security/dummy.c | 6 ++++++ > > security/security.c | 5 +++++ > > 11 files changed, 78 insertions(+), 3 deletions(-) > > > > > diff --git a/security/capability.c b/security/capability.c > > index dc2b66c..e23864e 100644 > > --- a/security/capability.c > > +++ b/security/capability.c > > @@ -37,6 +37,7 @@ static struct security_operations capability_ops = { > > > > .inode_setxattr = cap_inode_setxattr, > > .inode_removexattr = cap_inode_removexattr, > > + .inode_removexattr = cap_inode_killpriv, > > s/inode_removexattr/inode_killpriv/
Well crap - I had fixed that an hour before I sent it. Which makes me wonder which version I sent...
> Also, doesn't SELinux then need to define a corresponding hook function > to call the secondary module? Otherwise, it will fall back to the dummy > implementation and stacking selinux + capabilities with file caps won't > yield the right behavior.
Yes it does. Will fix that on resend.
thanks, -serge - 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/
| |