From owner-freebsd-hackers@freebsd.org Sat May 16 18:28:43 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 AECE22F9802; Sat, 16 May 2020 18:28:43 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) 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 49PYgv43vsz3M3p; Sat, 16 May 2020 18:28:43 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (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 79CD1854C; Sat, 16 May 2020 18:28:43 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f177.google.com with SMTP id f189so6071628qkd.5; Sat, 16 May 2020 11:28:43 -0700 (PDT) X-Gm-Message-State: AOAM531yf1gg7rAAsFyLhSnwvDajYezNNRBrpSl5cyayLvCxJG4jUQaU HD2Ec2iMi9F4pcpwR9bBtFaF3ef02+YmKFw3mMw= X-Google-Smtp-Source: ABdhPJxc/j7l84amDzf+f7rNCbxmr/AYNYxnQxP1kqm9nbioUJyIAvwtfCuTLmEVKmdiNCzcmU7jypra2xQm8m92RgY= X-Received: by 2002:a37:2711:: with SMTP id n17mr9071974qkn.430.1589653723013; Sat, 16 May 2020 11:28:43 -0700 (PDT) MIME-Version: 1.0 References: <202005161758.04GHwbpZ038671@fire.js.berklix.net> In-Reply-To: <202005161758.04GHwbpZ038671@fire.js.berklix.net> From: Kyle Evans Date: Sat, 16 May 2020 13:28:32 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" 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: Sat, 16 May 2020 18:28:43 -0000 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, Kyle Evans