Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 May 2020 13:28:32 -0500
From:      Kyle Evans <kevans@freebsd.org>
To:        "Julian H. Stacey" <jhs@berklix.com>
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>,  "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: [HEADSUP] Disallowing read() of a directory fd
Message-ID:  <CACNAnaHW03QT2Fd_Nf8bcb8w5AE6VBkwdCQR7rcoL5T5zYrN2A@mail.gmail.com>
In-Reply-To: <202005161758.04GHwbpZ038671@fire.js.berklix.net>
References:  <CACNAnaFapztQL3N4sWTv1-umh96xUeZPYUoQ3imX7fhCk5c0HA@mail.gmail.com> <202005161758.04GHwbpZ038671@fire.js.berklix.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 16, 2020 at 12:59 PM Julian H. Stacey <jhs@berklix.com> wrote:
>
> Kyle Evans wrote:
> > [... snip ...]
> > That said, I've written a MAC policy that can live atop the current
> > patch to lift all of the restrictions except the sysctl needing to be
> > set: https://people.freebsd.org/~kevans/mac-read_dir.diff -> I could
> > even be convinced fairly easily to commit it, if you'd find that
> > acceptable. The policy ends up looking generically useful, as you can
> > lift just the jail root restriction or you can allow any user to cat a
> > directory.
> >
> > Thanks,
> >
> > Kyle Evans
>
> Thanks,
> It's good if its all sysctl without reboot, (taking (phk's I recall) point
> about an fs not surviving a reboot)
>

Yup- assuming you're not in the perhaps rare situation where you both
need this *and* you can't get the kmod loaded, it's all sysctl-based.

> It sounds useful, if it allows 3 or is that more ? way choice between eg
> {old v. new} x { root v. non root } x { inside a jail v. outside } = 8 ?
>

It's not quite that flexible because this is harder to capture, it
allows three different possibilities:

- New behavior
- Old behavior
- Middle ground, where unprivileged users can't `cat .` but jail root can

#3 was thrown in because I suspect someone somewhere may not
necessarily care for preservation of any old users' capability to do
this, but for those systems where the previously cited 'jail root is
root' is true (since I think we agree that that can be the case, but
often isn't).

> If all of that, I guess we'd just be down to a relaxed consideration about
> what default mode was for now & later.
>
> If there was change there, we'd need to check what policy is about giving
> advance notice of changes in RELNOTES.
>
> If RELNOTES required long notice than wanted , that could be worked round
> easily by implementing code, & merely issuing notice that defaults would
> change to new policy later at releasese x.y.
>

Here's how this breaks down; these steps haven't been included in the
review thus far because I often just assume that it's clear this will
happen:

- UPDATING: Users of 13.0-CURRENT will receive notice via UPDATING
that this is changing, along with mention of the MAC policy to return
to the legacy behavior. Some bumps of this nature are to be expected
amongst -CURRENT, and this is how we communicate them to those
following along at home.

- RELNOTES: This will definitely be included in the 13.0 relnotes. I'm
tentatively planning to MFC some of the functionality
(security.bsd.allow_read_dir but with a default of 1 to preserve
branch behavior) to allow users of stable/12 to turn it off and get
the 13.0 behavior earlier if they want or see if it breaks any of
their stuff, which I will try and use as a vector to get the future
default change into the 12.2 release notes as well so that there's
plenty of advance notice. I suspect re@ will happily include it, given
the history.

> I took a quick glance at
> https://people.freebsd.org/~kevans/mac-read_dir.diff but I'm sorry
> loads of real life distraction h These kinds of bumps are to be expectedere. I'm sure others will want t
> read it. Thanks for working hard to cater for all cases ! :-)
>

This is fine. =-) Honestly, I have really been trying my best to
optimize the outcome for all of our users. I do fully believe at this
point in the discussion that the majority of our userbase is best
served by changing the default behavior here, and I want to be able to
do so without burning community relations.

My suspicion is that those of you that do make use of this, do so
infrequently and would happily or maybe even usually run a system
with:

root@viper:~# cat /boot/loader.conf
# Of course, this could instead be baked into your kernel config
mac_read_dir_load="YES"

root@viper:~# cat /etc/sysctl.conf
security.mac.read_dir.jail_root=1
# The following perhaps even turned off or commented out to serve just
as a reminder, until you actually need it
security.bsd.allow_read_dir=1

My working assumption being that you don't often do this as any old
unprivileged user, but might be doing so as jail root. Of course,
`security.mac.read_dir.jail_root=1` might instead be
`security.mac.read_dir.all_users=1` to fully follow the existing
behavior.

Thanks,

Kyle Evans



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaHW03QT2Fd_Nf8bcb8w5AE6VBkwdCQR7rcoL5T5zYrN2A>