From owner-freebsd-arch@freebsd.org Sat May 16 16:26:23 2020 Return-Path: Delivered-To: freebsd-arch@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 5940F2F66F5; Sat, 16 May 2020 16:26:23 +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 49PVyl1dx2z3CrH; Sat, 16 May 2020 16:26:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (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 2680C76B6; Sat, 16 May 2020 16:26:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f52.google.com with SMTP id g20so2644450qvb.9; Sat, 16 May 2020 09:26:23 -0700 (PDT) X-Gm-Message-State: AOAM531HrVnIwsiDY/xlC3WQk/DcdgGy2okwf7HpGJHuHkKl9kq9f2cV 4pl1B6r9aTFpWPoB9W+RgFuMhtDkCh96N/6opX4= X-Google-Smtp-Source: ABdhPJwr5nlj8YBBNBIITL7PfBdsTPYlMQnUCoVbA9fmFgt2VNocPcw4h8exB28ETDru9uJPaYj9/S6xUxjfZoTr1GA= X-Received: by 2002:a0c:f054:: with SMTP id b20mr8334283qvl.112.1589646382677; Sat, 16 May 2020 09:26:22 -0700 (PDT) MIME-Version: 1.0 References: <2ea8236f935a4c786a0f4f06ca1d3ea3@udns.ultimatedns.net> <202005161518.04GFIA0a099390@fire.js.berklix.net> In-Reply-To: <202005161518.04GFIA0a099390@fire.js.berklix.net> From: Kyle Evans Date: Sat, 16 May 2020 11:26:11 -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-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 16:26:23 -0000 On Sat, May 16, 2020 at 10:18 AM Julian H. Stacey wrote: > > Another use of "cat ." is to see names of transient files a tool > creates, & normaly deletes, if not aborting, so one can find same > name junk elsewhere, & search for tool causing junk, > & ensure other data files avoid using names that would be zapped. > > While blocking "cat ." might be worked round if not in a jail, & > or if using fsdb & sysctl etc, it would add to a more BSD specific > environment, where standard portable Unix skills was insufficient, > & more time needed to search & learn BSD extras. Every obstacle > costs employers time = money. > This scenario is just a bit too generic for me to be able to relate to, because I've never been in a situation where I would've had to or just randomly used `cat .` to discover junk files. This also isn't really a transferable skill to other modern OS and filesystems, as oftentimes they won't or can't give you anything useful with read(2). 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