SELinux Archive on lore.kernel.org
 help / color / 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
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 index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-19 19:30 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 publically 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

SELinux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \
		selinux@vger.kernel.org selinux@archiver.kernel.org
	public-inbox-index selinux


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux


AGPL code for this site: git clone https://public-inbox.org/ public-inbox