From owner-freebsd-hackers@freebsd.org Sun May 17 03:56:00 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3079213C6AA; Sun, 17 May 2020 03:56:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PpGR6KRjz3cgD; Sun, 17 May 2020 03:55:59 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id CE8E111818; Sun, 17 May 2020 03:55:59 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f53.google.com with SMTP id fb16so3104385qvb.5; Sat, 16 May 2020 20:55:59 -0700 (PDT) X-Gm-Message-State: AOAM532mLZd/ShKpOo0bH6vu4S23NS2wDY5E2atmzbpgljYA2X/2V7hd HcUxS+OSDJ79+axN+6XU0kK34tmW+yv9nnzk4Hk= X-Google-Smtp-Source: ABdhPJzDcMszdkeAtuyd0+q5mKNlfZggj17w7xMIb9PwuBvhth4xRkxWHW4uhNkJ9u+sRbeg/+GOK5Dgly1naUwTuik= X-Received: by 2002:a05:6214:40e:: with SMTP id z14mr9821619qvx.150.1589687759198; Sat, 16 May 2020 20:55:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Sat, 16 May 2020 22:55:48 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: bsd-lists@bsdforge.com Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "Julian H. Stacey" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2020 03:56:00 -0000 On Sat, May 16, 2020 at 4:42 PM Chris wrote: > > On Sat, 16 May 2020 13:28:32 -0500 Kyle Evans kevans@freebsd.org said > > > On Sat, May 16, 2020 at 12:59 PM Julian H. Stacey 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, > No. Thank *you*, Kyle. :-) > 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. > > While I have only glossed over your diff, and therefore can't (yet) > reasonably evaluate it. Do you anticipate any impact/changes to overall > performance? > MAC has its own performance issues, but I think mjg's put some work into mitigating that since mac_ntpd became commonplace. I wouldn't otherwise anticipate any real impact for anything but perhaps micro-benchmarks. Most requests coming into mac_read_dir will immediately return because it only handles the new privilege for read(2) of a dirfd. That specific path (read of a dirfd) has become elongated now that we need to check creds out in the MAC module and it bypasses the superuser policy if we're in a jail, so high volumes of directory read(2) might notice some kind of impact, but none of the scenarios that have been presented to me even qualify for medium volume and I would find it fairly unlikely if any high-volume scenario does exist. > 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. I look back fondly remembering waiting for tubes to warm up, and > threading/spooling up tapes. I don't remember being too fond of having to > wait for someone elses job to finish, so I could use the damn thing. ;-) > Sure, and I completely respect that. I would suspect that most of the people that I've been discussing this with have been hacking on systems since before I was even born (Net/1 appears to complete predate me, for example, by a couple of years), which is another reason why I'm willing to go the extra mile to make sure that it's a smooth transition. My goal isn't to sour everyone's cheerios, create heartburn, or obstruct people from just doing what they need to do periodically; my goal is to try and improve the user experience/security for the majority. Does it add a couple more knobs to do what's been easy for 35+ years? Yes, unfortunately, but the real need seems to be either infrequent enough that this isn't a major problem or it will just get thrown in /boot/loader.conf (or even embedded into kernel configs) and /etc/sysctl.conf to be forgotten about. Thanks, Kyle Evans