More fixes from wulf@

Okay, so turns out this is the REL_WHEEL, not REL_HWHEEL;
its just that all the offsets within the report are shifted
by one byte. I'm guessing this is the Report ID.

Fixes suggested by wulf@.

Get rid of vhold/vdrop. I've been running it for a few days
and it appears to work fine.

In D47391#1080971, @kib wrote:

This cannot be right.

If the file references vnode, vnode must be active and have the use count at least 1, because file vref-ed the vnode on open.

Second try.

This follows a somewhat similar fix in https://reviews.freebsd.org/D29323?id=86801. I can't say I have a proper understanding of what's going on here though.

In D44373#1076563, @markj wrote:

In D44373#1076525, @trasz wrote:

In D44373#1074357, @markj wrote:

In D44373#1074343, @trasz wrote:

In D44373#1072417, @markj wrote:

Reading the proposal, I sense that this would make capsicumization of command-line programs which convert argv[] entries to capabilities (i.e., which process a list of files) much easier. Rather than having to use cap_fileargs (which is expensive and has some functional thorns, and requires some refactoring to pass the casper channel around) or refactor everything to use openat() (not always practical), the program can instead

• open the root dir and working dir,
• limit rights on those dir fds,
• call cap_enter()
• call fchdir() and fchroot() with the aforementioned dirfds

Then, the program should be able to process argv[] entries without any further modification, which would make life much easier. This leaves open the possibility that the sandboxed process would be able to open files not listed in the argv[], but assuming that rights are appropriately limited on the dirfds, I think this is probably an acceptable tradeoff for many programs.

It would be quite nice if one could do this without requiring privileges. In particular, if one is just using fchroot() to make a dirfd visible to capsicum without actually changing the root directory (i.e., the root vnode doesn't change), can we get away without requiring that?

That's precisely the idea - and it explains it much better than my description above. And yes, fchroot(2) can be used unprivileged same way chroot(2) can, just set PROC_NO_NEW_PRIVS_ENABLE; for now you also need to set security.bsd.unprivileged_chroot=1.

Indeed, but if we start sandboxing command-line applications this way, they'll presumably be broken if someone sets security.bsd.unprivileged_chroot=0, which seems rather fragile. So, I'm wondering if calling fchroot() without actually changing the root vnode can be a special operation which doesn't require privilege checking.

Not sure if I follow. How would fchroot(2) work without changing the root vnode?

In the use-case I imagined originally, code would effectively do this:

dfd = open("/", O_DIRECTORY);
cap_rights_limit(dfd, ...)
cap_enter();
fchroot(dfd);
/* now applications can use open("/foo/bar"), subject to rights on `dfd`. */

Here, the root vnode isn't actually changing.

In D44373#1074357, @markj wrote:

In D44373#1074343, @trasz wrote:

In D44373#1072417, @markj wrote:

Reading the proposal, I sense that this would make capsicumization of command-line programs which convert argv[] entries to capabilities (i.e., which process a list of files) much easier. Rather than having to use cap_fileargs (which is expensive and has some functional thorns, and requires some refactoring to pass the casper channel around) or refactor everything to use openat() (not always practical), the program can instead

• open the root dir and working dir,
• limit rights on those dir fds,
• call cap_enter()
• call fchdir() and fchroot() with the aforementioned dirfds

Then, the program should be able to process argv[] entries without any further modification, which would make life much easier. This leaves open the possibility that the sandboxed process would be able to open files not listed in the argv[], but assuming that rights are appropriately limited on the dirfds, I think this is probably an acceptable tradeoff for many programs.

It would be quite nice if one could do this without requiring privileges. In particular, if one is just using fchroot() to make a dirfd visible to capsicum without actually changing the root directory (i.e., the root vnode doesn't change), can we get away without requiring that?

That's precisely the idea - and it explains it much better than my description above. And yes, fchroot(2) can be used unprivileged same way chroot(2) can, just set PROC_NO_NEW_PRIVS_ENABLE; for now you also need to set security.bsd.unprivileged_chroot=1.

Indeed, but if we start sandboxing command-line applications this way, they'll presumably be broken if someone sets security.bsd.unprivileged_chroot=0, which seems rather fragile. So, I'm wondering if calling fchroot() without actually changing the root vnode can be a special operation which doesn't require privilege checking.

In D44373#1072417, @markj wrote:

Reading the proposal, I sense that this would make capsicumization of command-line programs which convert argv[] entries to capabilities (i.e., which process a list of files) much easier. Rather than having to use cap_fileargs (which is expensive and has some functional thorns, and requires some refactoring to pass the casper channel around) or refactor everything to use openat() (not always practical), the program can instead

• open the root dir and working dir,
• limit rights on those dir fds,
• call cap_enter()
• call fchdir() and fchroot() with the aforementioned dirfds

Then, the program should be able to process argv[] entries without any further modification, which would make life much easier. This leaves open the possibility that the sandboxed process would be able to open files not listed in the argv[], but assuming that rights are appropriately limited on the dirfds, I think this is probably an acceptable tradeoff for many programs.

It would be quite nice if one could do this without requiring privileges. In particular, if one is just using fchroot() to make a dirfd visible to capsicum without actually changing the root directory (i.e., the root vnode doesn't change), can we get away without requiring that?

Two more nits from salvadore@

In D46710#1068643, @kib wrote:

In D46710#1067824, @trasz wrote:

In D46710#1067752, @kib wrote:

In D46710#1067690, @trasz wrote:

I think the way it works is that autofs_lookup() doesn't trigger when looking up the autofs directory itself, only when looking up inside that directory?

I do not think so. When lookup finds a mount point, it steps over it. So I do think that this is due to caching.

It's not (typically) a mountpoint though? Usually you'd have something like /net/server/share/; the /net is the autofs mount point, and /net/server/ is an ordinary synthetic autofs directory, not a mount point. And this is about looking up /net/server/share - a stat(2) on that shouldn't trigger mounting it.

Right. And what does prevent the autofs_lookup() from triggering the mount in this situation? It should, unless the vnode is present in namecache.

copyedits, one line per sentence.

In D46710#1067752, @kib wrote:

In D46710#1067690, @trasz wrote:

I think the way it works is that autofs_lookup() doesn't trigger when looking up the autofs directory itself, only when looking up inside that directory?

I do not think so. When lookup finds a mount point, it steps over it. So I do think that this is due to caching.

I think the way it works is that autofs_lookup() doesn't trigger when looking up the autofs directory itself, only when looking up inside that directory?

In D46710#1065280, @kib wrote:

In D46710#1065252, @trasz wrote:

I’m not sure I follow, but FreeBSD doesn’t mount on stat anyway, so why introduce the native flag instead of making the code consistently ignore the Linux one? Linux autofs semantics is broken in some interesting ways; we don’t need to port functionality that only exists to work around that brokenness.

Could you please explain how do we avoid triggering automount on stat? The autofs_mount_on_stat knob is mostly nop because the trigger happen during lookup preceeding the call to VOP_GETATTR().

I’m not sure I follow, but FreeBSD doesn’t mount on stat anyway, so why introduce the native flag instead of making the code consistently ignore the Linux one? Linux autofs semantics is broken in some interesting ways; we don’t need to port functionality that only exists to work around that brokenness.

Some more fixes from Brooks.

So... how do we proceed with this?

Drop wait6(2) for now

Improve the man page.

Man page rewording from gnn@

In D44373#1032959, @jonathan wrote:

@trasz : thanks for sending this review request. My general feeling is that I'm leery of relaxing the in-kernel security model, not just because of the potential for opening things we don't mean to open, but also because it complicates the model for those who are trying to understand it. "No global namespaces", while limiting, is a clearer rule than "no global namespaces unless you or your ancestor has previously called fchroot(2), unless-unless something has also called cap_enter(2) again to clear that magic vnode".

(And also an earlier version of this did exactly that wrt idtype, that’s why the title still mentions the “limited subset”; only after that I’ve discovered that you can’t wait for arbitrary PIDs anyway.)

I might be wrong, but isn’t this restriction already there, inherent to wait(2) APIs? You need to use kqueue to wait for non-children?

Sigh, a typo.

Man page fix from Brooks.

Use the right symbol version and bump Dd.

There's a separate review for vfork (https://reviews.freebsd.org/D39829). And yeah, I've pasted Robert the link to this one here :)

Add back procstat(1) bits and remove syscalls.map

As for CAP_FCHROOT - I think we should have it, if only for symmetry with CAP_FCHDIR. I don't really want to implement them - the lookup code isn't really suited for tracking rights for root and cwd, and so those two syscalls require full rights to succeed, not just a subset - but we could in the future.

Update.

Can you describe the dlopen threat model a bit more? My assumption is, a typical Capsicum-aware app wouldn't be setting the rootdir/curdir at all. Or, if it does, it could call cap_enter(2) again before calling dlopen(3), clearing those vnodes.

Fix panic which occured when the PID is specified explictly.
Also handle wait6(2). Add some documentation. Pacify a test.

I agree this should be documented somewhere, but at the moment wait(2) doesn't mention Capsicum at all, and capsicum(4) doesn't mention wait(2). Perhaps a paragraph in pdfork(2), something along the lines of "processes created with pdfork cannot be waited for by a parent running in capsicum(4) mode"?