Date: Sat, 16 May 2020 14:43:17 -0700 From: Chris <bsd-lists@BSDforge.com> To: Kyle Evans <kevans@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "Julian H. Stacey" <jhs@berklix.com> Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <b737eb69aad28aff0693fdab8159b86a@udns.ultimatedns.net> In-Reply-To: <CACNAnaHW03QT2Fd_Nf8bcb8w5AE6VBkwdCQR7rcoL5T5zYrN2A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 May 2020 13:28:32 -0500 Kyle Evans kevans@freebsd=2Eorg said > On Sat, May 16, 2020 at 12:59 PM Julian H=2E Stacey <jhs@berklix=2Ecom> wrote= : > > > > Kyle Evans wrote: > > > [=2E=2E=2E snip =2E=2E=2E] > > > 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=2Efreebsd=2Eorg/~kevans/mac-read_dir=2Ediff -> I could > > > even be convinced fairly easily to commit it, if you'd find that > > > acceptable=2E 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=2E > > > > > > Thanks, > > > > > > Kyle Evans > > > > Thanks, > > It's good if its all sysctl without reboot, (taking (phk's I recall) po= int > > about an fs not surviving a reboot) > > >=20 > 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=2E >=20 > > It sounds useful, if it allows 3 or is that more ? way choice between e= g > > {old v=2E new} x { root v=2E non root } x { inside a jail v=2E outside } =3D = 8 ? > > >=20 > It's not quite that flexible because this is harder to capture, it > allows three different possibilities: >=20 > - New behavior > - Old behavior > - Middle ground, where unprivileged users can't `cat =2E` but jail root can >=20 > #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)=2E >=20 > > If all of that, I guess we'd just be down to a relaxed consideration ab= out > > what default mode was for now & later=2E > > > > If there was change there, we'd need to check what policy is about givi= ng > > advance notice of changes in RELNOTES=2E > > > > If RELNOTES required long notice than wanted , that could be worked rou= nd > > easily by implementing code, & merely issuing notice that defaults woul= d > > change to new policy later at releasese x=2Ey=2E > > >=20 > 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: >=20 > - UPDATING: Users of 13=2E0-CURRENT will receive notice via UPDATING > that this is changing, along with mention of the MAC policy to return > to the legacy behavior=2E Some bumps of this nature are to be expected > amongst -CURRENT, and this is how we communicate them to those > following along at home=2E >=20 > - RELNOTES: This will definitely be included in the 13=2E0 relnotes=2E I'm > tentatively planning to MFC some of the functionality > (security=2Ebsd=2Eallow_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=2E0 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=2E2 release notes as well so that there's > plenty of advance notice=2E I suspect re@ will happily include it, given > the history=2E >=20 > > I took a quick glance at > > https://people=2Efreebsd=2Eorg/~kevans/mac-read_dir=2Ediff but I'm sorry > > loads of real life distraction h These kinds of bumps are to be expecte= dere=2E > > I'm sure others will want t > > read it=2E Thanks for working hard to cater for all cases ! :-) > > >=20 > This is fine=2E =3D-) Honestly, I have really been trying my best to > optimize the outcome for all of our users=2E 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=2E >=20 > 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: >=20 > root@viper:~# cat /boot/loader=2Econf > # Of course, this could instead be baked into your kernel config > mac_read_dir_load=3D"YES" >=20 > root@viper:~# cat /etc/sysctl=2Econf > security=2Emac=2Eread_dir=2Ejail_root=3D1 > # The following perhaps even turned off or commented out to serve just > as a reminder, until you actually need it > security=2Ebsd=2Eallow_read_dir=3D1 >=20 > My working assumption being that you don't often do this as any old > unprivileged user, but might be doing so as jail root=2E Of course, > `security=2Emac=2Eread_dir=2Ejail_root=3D1` might instead be > `security=2Emac=2Eread_dir=2Eall_users=3D1` to fully follow the existing > behavior=2E >=20 > Thanks, No=2E Thank *you*, Kyle=2E :-) I just want to take this opportunity to thank you for all the work you put into this -- both the semi-anticipated code, and perhaps more significantly, the _social_ work that went into getting this concept into a usable/functional state=2E While I have only glossed over your diff, and therefore can't (yet) reasonably evaluate it=2E Do you anticipate any impact/changes to overall performance? In closing; some of here have been hacking on this code since before Net/1, and are fairly sensitive about some new-comer messing with our UNIX heritage=2E I look back fondly remembering waiting for tubes to warm up, and threading/spooling up tapes=2E I don't remember being too fond of having to wait for someone elses job to finish, so I could use the damn thing=2E ;-) Thanks again! --Chris >=20 > Kyle Evans > _______________________________________________ > freebsd-hackers@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd=2Eorg= "
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b737eb69aad28aff0693fdab8159b86a>