All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taras Kondratiuk <takondra@cisco.com>
To: Paul Moore <paul@paul-moore.com>, Stephen Smalley <sds@tycho.nsa.gov>
Cc: linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov,
	xe-linux-external@cisco.com
Subject: Re: [RFC PATCH] selinux: add a fallback to defcontext for native labeling
Date: Tue, 02 Oct 2018 17:58:55 -0700	[thread overview]
Message-ID: <153852833597.8135.14322052015672451164@takondra-t460s> (raw)
In-Reply-To: <91112a5a-2e67-28cf-b8a5-b80dc9385bb7@tycho.nsa.gov>

Quoting Stephen Smalley (2018-10-02 12:41:54)
> On 10/02/2018 02:48 PM, Taras Kondratiuk wrote:
> > Quoting Stephen Smalley (2018-09-21 07:40:58)
> >> If we set the inode sid to the superblock def_sid on an invalid
> >> context, then we lose the association to the original context value.
> >> The support for deferred mapping of contexts requires allocating a new
> >> SID for the invalid context and storing that SID in the inode, so that
> >> if the context later becomes valid upon a policy update/reload, the
> >> inode SID will refer to the now valid context.
> >> To combine the two, we would need security_context_to_sid_core() to
> >> save the def_sid in the context structure for invalid contexts, and
> >> change sidtab_search_core() to use that value instead of
> >> SECINITSID_UNLABELED for invalid SIDs.  Then the inode would be
> >> treated as having the defcontext for access control and getxattr() w/o
> >> CAP_MAC_ADMIN purposes, but a subsequent policy update/reload that
> >> makes the context valid would automatically cause subsequent accesses
> >> to the inode to start using the original context value for access
> >> control and getxattr() purposes.  I think that's the behavior you
> >> want.
> >>
> > 
> > While implementing the change I've realized that storing default context
> > for sidtab_search_core() in the context structure is not enough to
> > achieve the desired behavior. The same invalid context may exist in two
> > mounts with different 'defcontext', so default context can't be a
> > property of a context structure.
> > 
> > One way to address it is to propagate default context to sidtab_search() all
> > the way from inode hooks. But that will be a bit intrusive. Something like
> > avc_has_perm_default() will need to be added.
> > 
> > Other way is to check for context validity in inode hooks and provide a default
> > context to avc_has_perm() if the inode's sid is invalid. But this may have
> > performance implication since validity check will be done each time in fast
> > path.
> > 
> > Do you see any other options?
> 
> I think the original approach is still best.  The def_sid can be part of 
> the context structure; you just need to update context_cmp() to compare 
> it (as part of the first return statement) so that the same invalid 
> context in two mounts with different defcontext= values will allocate 
> different SIDs.  Likewise context_cpy() needs to copy the def_sid.
> 
> As a separate matter, you should also modify 
> security_context_to_sid_force() to pass down the sbsec->def_sid so that 
> when userspace with CAP_MAC_ADMIN sets an invalid context on an inode, 
> the default context will be used in the same manner.

Thanks. That's really a better approach.

  reply	other threads:[~2018-10-03  0:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-19 16:52 [RFC PATCH] selinux: add a fallback to defcontext for native labeling Taras Kondratiuk
2018-09-19 18:47 ` Paul Moore
2018-09-19 19:00 ` Stephen Smalley
2018-09-20  2:41   ` Taras Kondratiuk
2018-09-20 14:49     ` Stephen Smalley
2018-09-20 22:59       ` Taras Kondratiuk
2018-09-21 14:40         ` Stephen Smalley
2018-09-24 21:17           ` Taras Kondratiuk
2018-09-25  3:46           ` Paul Moore
2018-09-25  5:45             ` Taras Kondratiuk
2018-09-25 14:00               ` Stephen Smalley
2018-09-25 16:03                 ` Paul Moore
2018-09-25 16:03                   ` Paul Moore
2018-09-25 16:39                   ` Stephen Smalley
2018-09-25 19:10                     ` Taras Kondratiuk
2018-10-02 18:48                       ` Taras Kondratiuk
2018-10-02 19:41                         ` Stephen Smalley
2018-10-03  0:58                           ` Taras Kondratiuk [this message]
2018-09-25 15:41               ` 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=153852833597.8135.14322052015672451164@takondra-t460s \
    --to=takondra@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=xe-linux-external@cisco.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.