linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: serge@hallyn.com (Serge E. Hallyn)
To: linux-security-module@vger.kernel.org
Subject: [PATCH] selinux: Perform both commoncap and selinux xattr checks
Date: Mon, 2 Oct 2017 10:52:37 -0500	[thread overview]
Message-ID: <20171002155237.GA17251@mail.hallyn.com> (raw)
In-Reply-To: <873771ipib.fsf_-_@xmission.com>

Quoting Eric W. Biederman (ebiederm at xmission.com):
> -UID: 28009                                                  
> Status: O
> 
> 
> When selinux is loaded the relax permission checks for writing
> security.capable are not honored.  Which keeps file capabilities
> from being used in user namespaces.
> 
> Stephen Smalley <sds@tycho.nsa.gov> writes:
> > Originally SELinux called the cap functions directly since there was no
> > stacking support in the infrastructure and one had to manually stack a
> > secondary module internally.  inode_setxattr and inode_removexattr
> > however were special cases because the cap functions would check
> > CAP_SYS_ADMIN for any non-capability attributes in the security.*
> > namespace, and we don't want to impose that requirement on setting
> > security.selinux.  Thus, we inlined the capabilities logic into the
> > selinux hook functions and adapted it appropriately.
> 
> Now that the permission checks in commoncap have evolved this
> inlining of their contents has become a problem.  So restructure
> selinux_inode_removexattr, and selinux_inode_setxattr to call
> both the corresponding cap_inode_ function and dentry_has_perm
> when the attribute is not a selinux security xattr.   This ensures
> the policies of both commoncap and selinux are enforced.
> 
> This results in smack and selinux having the same basic structure
> for setxattr and removexattr.  Performing their own special permission
> checks when it is their modules xattr being written to, and deferring
> to commoncap when that is not the case.  Then finally performing their
> generic module policy on all xattr writes.
> 
> This structure is fine when you only consider stacking with the
> commoncap lsm, but it becomes a problem if two lsms that don't want
> the commoncap security checks on their own attributes need to be
> stack.  This means there will need to be updates in the future as lsm
> stacking is improved, but at least now the structure between smack and
> selinux is common making the code easier to refactor.
> 
> This change also has the effect that selinux_linux_setotherxattr becomes
> unnecessary so it is removed.
> 
> Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
> Fixes: 7bbf0e052b76 ("[PATCH] selinux merge")
> Historical Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

This is hairy, but it looks right:

Reviewed-by: Serge Hallyn <serge@hallyn.com>

thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-10-02 15:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-28 22:34 [RFC][PATCH] security: Make the selinux setxattr and removexattr hooks behave Eric W. Biederman
2017-09-29  1:16 ` Casey Schaufler
2017-09-29 14:18   ` Stephen Smalley
2017-09-29 15:46     ` Casey Schaufler
2017-09-30 16:22       ` Eric W. Biederman
2017-09-30 17:01         ` Casey Schaufler
2017-09-30 20:40           ` Eric W. Biederman
2017-09-30 23:22             ` Casey Schaufler
2017-10-01  1:02               ` Eric W. Biederman
2017-10-01 18:52                 ` Casey Schaufler
2017-10-01 19:54                   ` Serge E. Hallyn
2017-10-01 22:11                   ` Eric W. Biederman
2017-09-29 12:36 ` Stephen Smalley
2017-10-02  3:26   ` Eric W. Biederman
2017-10-02 14:38   ` [PATCH] selinux: Perform both commoncap and selinux xattr checks Eric W. Biederman
2017-10-02 15:52     ` Serge E. Hallyn [this message]
2017-10-03 16:24     ` Stephen Smalley
2017-10-03 21:08     ` Paul Moore
2017-10-03 21:26       ` Eric W. Biederman
2017-10-04 14:53         ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171002155237.GA17251@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).