[HEADSUP] Disallowing read() of a directory fd

Kyle Evans kevans at freebsd.org
Sat May 16 17:52:41 UTC 2020


On Sat, May 16, 2020 at 11:26 AM Kyle Evans <kevans at freebsd.org> wrote:
>
> On Sat, May 16, 2020 at 10:18 AM Julian H. Stacey <jhs at berklix.com> 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.
>

I've finished up a manpage for this MAC module and the rest of the
build infrastructure, publishing it for review here:
https://reviews.freebsd.org/D24862 -> the formal dependency on the
previous review has been documented.

Thanks,

Kyle Evans


More information about the freebsd-arch mailing list