selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Jonathan Lebon <jlebon@redhat.com>
Cc: selinux@vger.kernel.org, Victor Kamensky <kamensky@cisco.com>
Subject: Re: [PATCH] selinux: allow labeling before policy is loaded
Date: Tue, 27 Aug 2019 20:55:58 -0400	[thread overview]
Message-ID: <CAHC9VhSLc=ORU2CkJSHiCmzTENEjk5Sy-dK2Op1btWgr17DZfg@mail.gmail.com> (raw)
In-Reply-To: <20190819193032.848-1-jlebon@redhat.com>

On Mon, Aug 19, 2019 at 3:31 PM Jonathan Lebon <jlebon@redhat.com> wrote:
>
> Currently, the SELinux LSM prevents one from setting the
> `security.selinux` xattr on an inode without a policy first being
> loaded. However, this restriction is problematic: it makes it impossible
> to have newly created files with the correct label before actually
> loading the policy.
>
> This is relevant in distributions like Fedora, where the policy is
> loaded by systemd shortly after pivoting out of the initrd. In such
> instances, all files created prior to pivoting will be unlabeled. One
> then has to relabel them after pivoting, an operation which inherently
> races with other processes trying to access those same files.
>
> Going further, there are use cases for creating the entire root
> filesystem on first boot from the initrd (e.g. Container Linux supports
> this today[1], and we'd like to support it in Fedora CoreOS as well[2]).
> One can imagine doing this in two ways: at the block device level (e.g.
> laying down a disk image), or at the filesystem level. In the former,
> labeling can simply be part of the image. But even in the latter
> scenario, one still really wants to be able to set the right labels when
> populating the new filesystem.
>
> This patch enables this by changing behaviour in the following two ways:
> 1. allow `setxattr` on mounts without `SBLABEL_MNT` (which is all of
>    them if no policy is loaded yet)
> 2. don't try to set the in-core inode SID if we're not initialized;
>    instead leave it as `LABEL_INVALID` so that revalidation may be
>    attempted at a later time
>
> Note the first hunk of this patch is functionally the same as a
> previously discussed one[3], though it was part of a larger series which
> wasn't accepted.
>
> Co-developed-by: Victor Kamensky <kamensky@cisco.com>
> Signed-off-by: Victor Kamensky <kamensky@cisco.com>
> Signed-off-by: Jonathan Lebon <jlebon@redhat.com>
>
> [1] https://coreos.com/os/docs/latest/root-filesystem-placement.html
> [2] https://github.com/coreos/fedora-coreos-tracker/issues/94
> [3] https://www.spinics.net/lists/linux-initramfs/msg04593.html
> ---
>  security/selinux/hooks.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)

...

> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 94de51628..faf93e9f8 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -3143,7 +3143,7 @@ static int selinux_inode_setxattr(struct dentry *dentry, const char *name,
>         }
>
>         sbsec = inode->i_sb->s_security;
> -       if (!(sbsec->flags & SBLABEL_MNT))
> +       if (!(sbsec->flags & SBLABEL_MNT) && selinux_state.initialized)
>                 return -EOPNOTSUPP;

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().

  int selinux_inode_setxattr(...)
  {

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

    if (!selinux_state.initialized)
      return (inode_owner_or_capable(inode) ? 0 : -EPERM);

    if (sbsec & SBLABEL_MNT)
      ...

    if (!inode_owner_or_capable(inode)
      ...

    ...
  }

-- 
paul moore
www.paul-moore.com

  parent reply	other threads:[~2019-08-28  0:56 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 [this message]
2019-09-11 21:28   ` Jonathan Lebon
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='CAHC9VhSLc=ORU2CkJSHiCmzTENEjk5Sy-dK2Op1btWgr17DZfg@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=jlebon@redhat.com \
    --cc=kamensky@cisco.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).