Re: https://reviews.freebsd.org/D57255 - migrating cut and rev

On Mon, Jun 29, 2026 at 05:11:00AM +0300, Konstantin Belousov wrote:
> On Mon, Jun 15, 2026 at 11:48:52AM -0400, Mark Johnston wrote:
> > On Thu, Jun 11, 2026 at 03:29:34PM -0400, Mark Johnston wrote:
> > > On Thu, Jun 11, 2026 at 02:04:17PM -0400, Ed Maste wrote:
> > > > On Fri, 5 Jun 2026 at 10:46, Adrian Chadd <[email protected]> wrote:
> > > > >
> > > > > I'd rather not add command line options / environment settings that can disable
> > > > > sandboxing. These should be cheap operations.
> > > > 
> > > > Yeah, we don't really want to have this be a command-line option.
> > > > 
> > > > The performance issue is really just a consequence of process-based
> > > > privilege separation. We could enter capability mode when processing
> > > > the last (or only) file specified on the command line (or stdio),
> > > > giving us the benefit of sandboxing for a large fraction of uses of
> > > > these tools without incurring much overhead.
> > > 
> > > For these simple "filter" programs which read some set of user-specified
> > > input files, an alternative is to do something like the following:
> > > 
> > > 1. Pre-open the root directory and cwd, and limit rights on the
> > >    directory fds.  CAP_READ+CAP_SEEK+CAP_FSTAT is probably enough for
> > >    most applications.
> > > 2. Enter capability mode.
> > > 3. When opening files, open relative paths relative to the cwd
> > >    descriptor, and absolute paths relative to the root dfd.
> > > 
> > > This gives the application limited access to the filesystem, but it can
> > > only write data to the output stream, can't make network connections,
> > > etc..  This is not as constrained as a proper Capsicum sandbox of
> > > course, but it's simpler and cheaper to integrate.  It is morally
> > > similar to calling pledge("rpath"), I believe.  
> > > 
> > > We could go further and modify fchroot() and fchdir() to save the rights
> > > associated with the user-specified fd in the process' pwd structure, and
> > > then require that all lookups relative to the root or cwd be limited by
> > > those saved rights.  That is, if I do something like
> > > 
> > > 	rfd = open("/", O_DIRECTORY);
> > > 	cap_rights_limit(rfd, cap_rights_init(&rights, CAP_READ, CAP_LOOKUP, CAP_PREAD));
> > > 	fchroot(rfd);
> > > 	fd = open("/foo/bar/baz", O_RDWR);
> > > 
> > > then rights on "fd" would automatically be limited by those on "rfd",
> > > just as if I had instead done
> > > 
> > > 	fd = openat(rfd, "foo/bar/baz", O_RDWR);
> > > 
> > > To make this more useful, we would have to allow openat(AT_FDCWD, ...)
> > > in capability mode, provided that the process called fchroot()/fchdir()
> > > first.  That would save the pain of converting all open("/foo/bar/baz")
> > > calls to openat(rfd, "foo/bar/baz") etc..
> Why not save the rights in pwd on entering the capability mode always,
> and not allowing AT_FDCWD always?
> 
> Further fchdir() could restrict the visibility much tighter, e.g. by
> doing fchdir() to /var/empty.
This probably requires a new version of cap_enter(2), say
	int cap_enter1(int flags)
with a flag specifying the new behavior WRT the '/' and cwd.

> 
> > > 
> > > Is this a terrible idea for some reason?
> > 
> > https://reviews.freebsd.org/D57599 demonstrates what I meant.  It allows
> > cat to run in a relatively tight sandbox without forking.
> > 
> > If the rest of my proposal is implemented, it would be able to use
> > getaddrinfo() again too; currently this fails because /etc/nsswitch.conf
> > can't be opened in capability mode.