Possibly unwanted rootcontext= behavior?

Possibly unwanted rootcontext= behavior?

[Ondrej Mosnacek]

Hello everyone,

while trying to fix the NFS rootcontext= issue, I realized that this
funny thing is possible:

# mount -o rootcontext=system_u:object_r:lib_t:s0 -t tmpfs tmpfs /mnt
# ls -lZd /mnt
drwxrwxrwt. 2 root root system_u:object_r:lib_t:s0 40 nov  5 07:30 /mnt
# mount
[...]
tmpfs on /mnt type tmpfs
(rw,relatime,rootcontext=system_u:object_r:lib_t:s0,seclabel)
# chcon -t bin_t /mnt
# ls -lZd /mnt
drwxrwxrwt. 2 root root system_u:object_r:bin_t:s0 40 nov  5 07:30 /mnt
# mount
[...]
tmpfs on /mnt type tmpfs
(rw,relatime,rootcontext=system_u:object_r:bin_t:s0,seclabel)

I.e. if you mount a tree with rootcontext=<oldctx> and then relabel
the root node to <newctx>, the displayed mount options will report
rootcontext=<newctx> instead of rootcontext=<oldctx>. A side effect is
that if you try to mount the same superblock again, it will only
permit you to mount with rootcontext=<newctx>, not with
rootcontext=<oldctx>.

Is that intended, bad, or "weird, but doesn't matter" behavior?

I have a halfway written patch to disallow altering the root node's
context when mounted with rootcontext=, but I'm not sure if that's the
right thing to do or not.

Thanks,

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.

Re: Possibly unwanted rootcontext= behavior?

[Stephen Smalley]

On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> Hello everyone,
>
> while trying to fix the NFS rootcontext= issue, I realized that this
> funny thing is possible:
>
> # mount -o rootcontext=system_u:object_r:lib_t:s0 -t tmpfs tmpfs /mnt
> # ls -lZd /mnt
> drwxrwxrwt. 2 root root system_u:object_r:lib_t:s0 40 nov  5 07:30 /mnt
> # mount
> [...]
> tmpfs on /mnt type tmpfs
> (rw,relatime,rootcontext=system_u:object_r:lib_t:s0,seclabel)
> # chcon -t bin_t /mnt
> # ls -lZd /mnt
> drwxrwxrwt. 2 root root system_u:object_r:bin_t:s0 40 nov  5 07:30 /mnt
> # mount
> [...]
> tmpfs on /mnt type tmpfs
> (rw,relatime,rootcontext=system_u:object_r:bin_t:s0,seclabel)
>
> I.e. if you mount a tree with rootcontext=<oldctx> and then relabel
> the root node to <newctx>, the displayed mount options will report
> rootcontext=<newctx> instead of rootcontext=<oldctx>. A side effect is
> that if you try to mount the same superblock again, it will only
> permit you to mount with rootcontext=<newctx>, not with
> rootcontext=<oldctx>.
>
> Is that intended, bad, or "weird, but doesn't matter" behavior?

I'd say it is bad.

> I have a halfway written patch to disallow altering the root node's
> context when mounted with rootcontext=, but I'm not sure if that's the
> right thing to do or not.

Probably the better fix would be to save the original rootcontext SID
as a new field of the
superblock security struct and use that both when displaying the mount
options and when
comparing old and new mount options instead of what happens to be
assigned to the root
inode at the time.

Re: Possibly unwanted rootcontext= behavior?

[Paul Moore]

On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > Hello everyone,
> >
> > while trying to fix the NFS rootcontext= issue, I realized that this
> > funny thing is possible:
> >
> > # mount -o rootcontext=system_u:object_r:lib_t:s0 -t tmpfs tmpfs /mnt
> > # ls -lZd /mnt
> > drwxrwxrwt. 2 root root system_u:object_r:lib_t:s0 40 nov  5 07:30 /mnt
> > # mount
> > [...]
> > tmpfs on /mnt type tmpfs
> > (rw,relatime,rootcontext=system_u:object_r:lib_t:s0,seclabel)
> > # chcon -t bin_t /mnt
> > # ls -lZd /mnt
> > drwxrwxrwt. 2 root root system_u:object_r:bin_t:s0 40 nov  5 07:30 /mnt
> > # mount
> > [...]
> > tmpfs on /mnt type tmpfs
> > (rw,relatime,rootcontext=system_u:object_r:bin_t:s0,seclabel)
> >
> > I.e. if you mount a tree with rootcontext=<oldctx> and then relabel
> > the root node to <newctx>, the displayed mount options will report
> > rootcontext=<newctx> instead of rootcontext=<oldctx>. A side effect is
> > that if you try to mount the same superblock again, it will only
> > permit you to mount with rootcontext=<newctx>, not with
> > rootcontext=<oldctx>.
> >
> > Is that intended, bad, or "weird, but doesn't matter" behavior?
>
> I'd say it is bad.
>
> > I have a halfway written patch to disallow altering the root node's
> > context when mounted with rootcontext=, but I'm not sure if that's the
> > right thing to do or not.
>
> Probably the better fix would be to save the original rootcontext SID
> as a new field of the
> superblock security struct and use that both when displaying the mount
> options and when
> comparing old and new mount options instead of what happens to be
> assigned to the root
> inode at the time.

I worry that would be confusing, allowing the root inode to be
relabeled yet still showing the old label in the mount options.  It
would seem that simply blocking a root inode relabel when a
rootcontext is specified would be the cleanest choice, assuming
existing systems do not rely on this behavior.

Ondrej, Stephen, any idea how common this is on normal systems?  My
gut feeling says "not very common", but that is just a guess.

-- 
paul moore
www.paul-moore.com

Re: Possibly unwanted rootcontext= behavior?

[Ondrej Mosnacek]

On Thu, Nov 5, 2020 at 4:31 PM Paul Moore <paul@paul-moore.com> wrote:
> On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> > On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > >
> > > Hello everyone,
> > >
> > > while trying to fix the NFS rootcontext= issue, I realized that this
> > > funny thing is possible:
> > >
> > > # mount -o rootcontext=system_u:object_r:lib_t:s0 -t tmpfs tmpfs /mnt
> > > # ls -lZd /mnt
> > > drwxrwxrwt. 2 root root system_u:object_r:lib_t:s0 40 nov  5 07:30 /mnt
> > > # mount
> > > [...]
> > > tmpfs on /mnt type tmpfs
> > > (rw,relatime,rootcontext=system_u:object_r:lib_t:s0,seclabel)
> > > # chcon -t bin_t /mnt
> > > # ls -lZd /mnt
> > > drwxrwxrwt. 2 root root system_u:object_r:bin_t:s0 40 nov  5 07:30 /mnt
> > > # mount
> > > [...]
> > > tmpfs on /mnt type tmpfs
> > > (rw,relatime,rootcontext=system_u:object_r:bin_t:s0,seclabel)
> > >
> > > I.e. if you mount a tree with rootcontext=<oldctx> and then relabel
> > > the root node to <newctx>, the displayed mount options will report
> > > rootcontext=<newctx> instead of rootcontext=<oldctx>. A side effect is
> > > that if you try to mount the same superblock again, it will only
> > > permit you to mount with rootcontext=<newctx>, not with
> > > rootcontext=<oldctx>.
> > >
> > > Is that intended, bad, or "weird, but doesn't matter" behavior?
> >
> > I'd say it is bad.
> >
> > > I have a halfway written patch to disallow altering the root node's
> > > context when mounted with rootcontext=, but I'm not sure if that's the
> > > right thing to do or not.
> >
> > Probably the better fix would be to save the original rootcontext SID
> > as a new field of the
> > superblock security struct and use that both when displaying the mount
> > options and when
> > comparing old and new mount options instead of what happens to be
> > assigned to the root
> > inode at the time.
>
> I worry that would be confusing, allowing the root inode to be
> relabeled yet still showing the old label in the mount options.  It
> would seem that simply blocking a root inode relabel when a
> rootcontext is specified would be the cleanest choice, assuming
> existing systems do not rely on this behavior.
>
> Ondrej, Stephen, any idea how common this is on normal systems?  My
> gut feeling says "not very common", but that is just a guess.

I don't even know what use case it's supposed to solve :) I suppose if
you freshly format some storage drive and you want the root dir to be
labeled immediately after mounting, rootcontext= could be useful. For
such a use case Stephen's approach would make sense (you might still
want to eventually relabel the root dir to something else), but there
are some gotchas... For example, the label is initially set only in
the inode security struct, but not written to the xattrs (I only
looked at the code briefly, I could be wrong here), so you would still
need to manually set the label on the root directory after mounting
for the label to persist. And if you remount the superblock after
changing the label, the internal label will be reset to the old one
(which you are forced to specify in the mount options), but again not
persistently. That's all very unintuitive.

So, IMHO, good ways to fix it are either disallowing changing the
label altogether, or making sure the label is propagated to the xattrs
(if supported) and allowing to remount with a different rootcontext=
option (or with no rootcontext). But that's only if I guessed the use
case correctly.

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.

Re: Possibly unwanted rootcontext= behavior?

[Stephen Smalley]

On Thu, Nov 5, 2020 at 12:22 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Thu, Nov 5, 2020 at 4:31 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > > On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > while trying to fix the NFS rootcontext= issue, I realized that this
> > > > funny thing is possible:
> > > >
> > > > # mount -o rootcontext=system_u:object_r:lib_t:s0 -t tmpfs tmpfs /mnt
> > > > # ls -lZd /mnt
> > > > drwxrwxrwt. 2 root root system_u:object_r:lib_t:s0 40 nov  5 07:30 /mnt
> > > > # mount
> > > > [...]
> > > > tmpfs on /mnt type tmpfs
> > > > (rw,relatime,rootcontext=system_u:object_r:lib_t:s0,seclabel)
> > > > # chcon -t bin_t /mnt
> > > > # ls -lZd /mnt
> > > > drwxrwxrwt. 2 root root system_u:object_r:bin_t:s0 40 nov  5 07:30 /mnt
> > > > # mount
> > > > [...]
> > > > tmpfs on /mnt type tmpfs
> > > > (rw,relatime,rootcontext=system_u:object_r:bin_t:s0,seclabel)
> > > >
> > > > I.e. if you mount a tree with rootcontext=<oldctx> and then relabel
> > > > the root node to <newctx>, the displayed mount options will report
> > > > rootcontext=<newctx> instead of rootcontext=<oldctx>. A side effect is
> > > > that if you try to mount the same superblock again, it will only
> > > > permit you to mount with rootcontext=<newctx>, not with
> > > > rootcontext=<oldctx>.
> > > >
> > > > Is that intended, bad, or "weird, but doesn't matter" behavior?
> > >
> > > I'd say it is bad.
> > >
> > > > I have a halfway written patch to disallow altering the root node's
> > > > context when mounted with rootcontext=, but I'm not sure if that's the
> > > > right thing to do or not.
> > >
> > > Probably the better fix would be to save the original rootcontext SID
> > > as a new field of the
> > > superblock security struct and use that both when displaying the mount
> > > options and when
> > > comparing old and new mount options instead of what happens to be
> > > assigned to the root
> > > inode at the time.
> >
> > I worry that would be confusing, allowing the root inode to be
> > relabeled yet still showing the old label in the mount options.  It
> > would seem that simply blocking a root inode relabel when a
> > rootcontext is specified would be the cleanest choice, assuming
> > existing systems do not rely on this behavior.
> >
> > Ondrej, Stephen, any idea how common this is on normal systems?  My
> > gut feeling says "not very common", but that is just a guess.
>
> I don't even know what use case it's supposed to solve :) I suppose if
> you freshly format some storage drive and you want the root dir to be
> labeled immediately after mounting, rootcontext= could be useful. For
> such a use case Stephen's approach would make sense (you might still
> want to eventually relabel the root dir to something else), but there
> are some gotchas... For example, the label is initially set only in
> the inode security struct, but not written to the xattrs (I only
> looked at the code briefly, I could be wrong here), so you would still
> need to manually set the label on the root directory after mounting
> for the label to persist. And if you remount the superblock after
> changing the label, the internal label will be reset to the old one
> (which you are forced to specify in the mount options), but again not
> persistently. That's all very unintuitive.
>
> So, IMHO, good ways to fix it are either disallowing changing the
> label altogether, or making sure the label is propagated to the xattrs
> (if supported) and allowing to remount with a different rootcontext=
> option (or with no rootcontext). But that's only if I guessed the use
> case correctly.

I think the original use case was primarily tmpfs mounts, so that e.g.
one could mount a tmpfs on /dev that is immediately labeled with
device_t.

Not fundamentally opposed to preventing relabeling afterward but
always possible that could break existing userspace somewhere.

Re: Possibly unwanted rootcontext= behavior?

[Stephen Smalley]

On Thu, Nov 5, 2020 at 12:28 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, Nov 5, 2020 at 12:22 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > On Thu, Nov 5, 2020 at 4:31 PM Paul Moore <paul@paul-moore.com> wrote:
> > > On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > > On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > >
> > > > > Hello everyone,
> > > > >
> > > > > while trying to fix the NFS rootcontext= issue, I realized that this
> > > > > funny thing is possible:
> > > > >
> > > > > # mount -o rootcontext=system_u:object_r:lib_t:s0 -t tmpfs tmpfs /mnt
> > > > > # ls -lZd /mnt
> > > > > drwxrwxrwt. 2 root root system_u:object_r:lib_t:s0 40 nov  5 07:30 /mnt
> > > > > # mount
> > > > > [...]
> > > > > tmpfs on /mnt type tmpfs
> > > > > (rw,relatime,rootcontext=system_u:object_r:lib_t:s0,seclabel)
> > > > > # chcon -t bin_t /mnt
> > > > > # ls -lZd /mnt
> > > > > drwxrwxrwt. 2 root root system_u:object_r:bin_t:s0 40 nov  5 07:30 /mnt
> > > > > # mount
> > > > > [...]
> > > > > tmpfs on /mnt type tmpfs
> > > > > (rw,relatime,rootcontext=system_u:object_r:bin_t:s0,seclabel)
> > > > >
> > > > > I.e. if you mount a tree with rootcontext=<oldctx> and then relabel
> > > > > the root node to <newctx>, the displayed mount options will report
> > > > > rootcontext=<newctx> instead of rootcontext=<oldctx>. A side effect is
> > > > > that if you try to mount the same superblock again, it will only
> > > > > permit you to mount with rootcontext=<newctx>, not with
> > > > > rootcontext=<oldctx>.
> > > > >
> > > > > Is that intended, bad, or "weird, but doesn't matter" behavior?
> > > >
> > > > I'd say it is bad.
> > > >
> > > > > I have a halfway written patch to disallow altering the root node's
> > > > > context when mounted with rootcontext=, but I'm not sure if that's the
> > > > > right thing to do or not.
> > > >
> > > > Probably the better fix would be to save the original rootcontext SID
> > > > as a new field of the
> > > > superblock security struct and use that both when displaying the mount
> > > > options and when
> > > > comparing old and new mount options instead of what happens to be
> > > > assigned to the root
> > > > inode at the time.
> > >
> > > I worry that would be confusing, allowing the root inode to be
> > > relabeled yet still showing the old label in the mount options.  It
> > > would seem that simply blocking a root inode relabel when a
> > > rootcontext is specified would be the cleanest choice, assuming
> > > existing systems do not rely on this behavior.
> > >
> > > Ondrej, Stephen, any idea how common this is on normal systems?  My
> > > gut feeling says "not very common", but that is just a guess.
> >
> > I don't even know what use case it's supposed to solve :) I suppose if
> > you freshly format some storage drive and you want the root dir to be
> > labeled immediately after mounting, rootcontext= could be useful. For
> > such a use case Stephen's approach would make sense (you might still
> > want to eventually relabel the root dir to something else), but there
> > are some gotchas... For example, the label is initially set only in
> > the inode security struct, but not written to the xattrs (I only
> > looked at the code briefly, I could be wrong here), so you would still
> > need to manually set the label on the root directory after mounting
> > for the label to persist. And if you remount the superblock after
> > changing the label, the internal label will be reset to the old one
> > (which you are forced to specify in the mount options), but again not
> > persistently. That's all very unintuitive.
> >
> > So, IMHO, good ways to fix it are either disallowing changing the
> > label altogether, or making sure the label is propagated to the xattrs
> > (if supported) and allowing to remount with a different rootcontext=
> > option (or with no rootcontext). But that's only if I guessed the use
> > case correctly.
>
> I think the original use case was primarily tmpfs mounts, so that e.g.
> one could mount a tmpfs on /dev that is immediately labeled with
> device_t.
>
> Not fundamentally opposed to preventing relabeling afterward but
> always possible that could break existing userspace somewhere.

commit 0808925ea5684a0ce25483b30e94d4f398804978
Author: Eric Paris <eparis@parisplace.org>
Date:   Mon Jul 10 04:43:55 2006 -0700

    [PATCH] SELinux: add rootcontext= option to label root inode when mounting

    Introduce a new rootcontext= option to FS mounting.  This option will allow
    you to explicitly label the root inode of an FS being mounted before that
    FS or inode because visible to userspace.  This was found to be useful for
    things like stateless linux, see
    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190001

    Signed-off-by: Eric Paris <eparis@parisplace.org>
    Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
    Signed-off-by: James Morris <jmorris@namei.org>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Re: Possibly unwanted rootcontext= behavior?

[Paul Moore]

On Thu, Nov 5, 2020 at 12:28 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Thu, Nov 5, 2020 at 12:22 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > On Thu, Nov 5, 2020 at 4:31 PM Paul Moore <paul@paul-moore.com> wrote:
> > > On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > > On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > > >
> > > > > Hello everyone,
> > > > >
> > > > > while trying to fix the NFS rootcontext= issue, I realized that this
> > > > > funny thing is possible:
> > > > >
> > > > > # mount -o rootcontext=system_u:object_r:lib_t:s0 -t tmpfs tmpfs /mnt
> > > > > # ls -lZd /mnt
> > > > > drwxrwxrwt. 2 root root system_u:object_r:lib_t:s0 40 nov  5 07:30 /mnt
> > > > > # mount
> > > > > [...]
> > > > > tmpfs on /mnt type tmpfs
> > > > > (rw,relatime,rootcontext=system_u:object_r:lib_t:s0,seclabel)
> > > > > # chcon -t bin_t /mnt
> > > > > # ls -lZd /mnt
> > > > > drwxrwxrwt. 2 root root system_u:object_r:bin_t:s0 40 nov  5 07:30 /mnt
> > > > > # mount
> > > > > [...]
> > > > > tmpfs on /mnt type tmpfs
> > > > > (rw,relatime,rootcontext=system_u:object_r:bin_t:s0,seclabel)
> > > > >
> > > > > I.e. if you mount a tree with rootcontext=<oldctx> and then relabel
> > > > > the root node to <newctx>, the displayed mount options will report
> > > > > rootcontext=<newctx> instead of rootcontext=<oldctx>. A side effect is
> > > > > that if you try to mount the same superblock again, it will only
> > > > > permit you to mount with rootcontext=<newctx>, not with
> > > > > rootcontext=<oldctx>.
> > > > >
> > > > > Is that intended, bad, or "weird, but doesn't matter" behavior?
> > > >
> > > > I'd say it is bad.
> > > >
> > > > > I have a halfway written patch to disallow altering the root node's
> > > > > context when mounted with rootcontext=, but I'm not sure if that's the
> > > > > right thing to do or not.
> > > >
> > > > Probably the better fix would be to save the original rootcontext SID
> > > > as a new field of the
> > > > superblock security struct and use that both when displaying the mount
> > > > options and when
> > > > comparing old and new mount options instead of what happens to be
> > > > assigned to the root
> > > > inode at the time.
> > >
> > > I worry that would be confusing, allowing the root inode to be
> > > relabeled yet still showing the old label in the mount options.  It
> > > would seem that simply blocking a root inode relabel when a
> > > rootcontext is specified would be the cleanest choice, assuming
> > > existing systems do not rely on this behavior.
> > >
> > > Ondrej, Stephen, any idea how common this is on normal systems?  My
> > > gut feeling says "not very common", but that is just a guess.
> >
> > I don't even know what use case it's supposed to solve :) I suppose if
> > you freshly format some storage drive and you want the root dir to be
> > labeled immediately after mounting, rootcontext= could be useful. For
> > such a use case Stephen's approach would make sense (you might still
> > want to eventually relabel the root dir to something else), but there
> > are some gotchas... For example, the label is initially set only in
> > the inode security struct, but not written to the xattrs (I only
> > looked at the code briefly, I could be wrong here), so you would still
> > need to manually set the label on the root directory after mounting
> > for the label to persist. And if you remount the superblock after
> > changing the label, the internal label will be reset to the old one
> > (which you are forced to specify in the mount options), but again not
> > persistently. That's all very unintuitive.
> >
> > So, IMHO, good ways to fix it are either disallowing changing the
> > label altogether, or making sure the label is propagated to the xattrs
> > (if supported) and allowing to remount with a different rootcontext=
> > option (or with no rootcontext). But that's only if I guessed the use
> > case correctly.
>
> I think the original use case was primarily tmpfs mounts, so that e.g.
> one could mount a tmpfs on /dev that is immediately labeled with
> device_t.
>
> Not fundamentally opposed to preventing relabeling afterward but
> always possible that could break existing userspace somewhere.

I'd be curious to see what sort of breakage, if any, we might see if
we blocked the relabel when rootcontext is in use.  Ondrej, any chance
you can finish that patch enough to do some basic testing?

-- 
paul moore
www.paul-moore.com