Re: Possibly unwanted rootcontext= behavior?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
> On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> 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



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux