selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Lebon <jlebon@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: selinux@vger.kernel.org, Victor Kamensky <kamensky@cisco.com>
Subject: Re: [PATCH] selinux: allow labeling before policy is loaded
Date: Wed, 11 Sep 2019 17:28:29 -0400	[thread overview]
Message-ID: <CACpbjYoR19bm2-DDJafnSNPcEt6XLK-ZFBCJ6=UpBQDmnSVKwg@mail.gmail.com> (raw)
In-Reply-To: <CAHC9VhSLc=ORU2CkJSHiCmzTENEjk5Sy-dK2Op1btWgr17DZfg@mail.gmail.com>

On Tue, Aug 27, 2019 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> As I'm looking at this, I'm wondering why we don't just bail out early
> if the policy isn't loaded?  The context lookup and permission checks
> later in the function are pretty much useless if the policy hasn't
> been loaded (they are just going to return defaults/allow), I think
> the only thing we would need to check would be
> inode_owner_or_capable().

Yes, I think you're correct. Though in that case, would it make sense
to just do the inode_owner_or_capable() check once upfront instead?

  int selinux_inode_setxattr(...)
  {

    if (strcmp(name, XATTR_NAME_SELINUX)) {
      ...
    }

    if (!inode_owner_or_capable(inode)
      ...

    if (!selinux_state.initialized)
      return 0;

    if (sbsec & SBLABEL_MNT)
      ...

    ...
  }

Hmm, though I guess it does change the behaviour slightly even in the
initialized case by returning EPERM first where before we might've
returned EOPNOTSUPP (I've seen userspace code which subtly relied on
the order in which the kernel checks for error conditions). I'm happy
to be conservative and go with your approach if you prefer.

  reply	other threads:[~2019-09-11 21:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-19 19:30 [PATCH] selinux: allow labeling before policy is loaded Jonathan Lebon
2019-08-19 19:49 ` Dominick Grift
2019-08-19 20:05 ` Dominick Grift
2019-08-19 21:11   ` Jonathan Lebon
2019-08-28  0:55 ` Paul Moore
2019-09-11 21:28   ` Jonathan Lebon [this message]
2019-09-11 23:56     ` 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='CACpbjYoR19bm2-DDJafnSNPcEt6XLK-ZFBCJ6=UpBQDmnSVKwg@mail.gmail.com' \
    --to=jlebon@redhat.com \
    --cc=kamensky@cisco.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@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).