Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view


Theo de Raadt-2
I wanted to give an update that a two pledge-related changes are being
worked on.  The semantics and integration are complicated so it is
taking some time.

One is execpromises.  This will become the 2nd argument of pledge().
This allows one to set the pledge for the new image after pledge
"exec"-allowed execve().  A warning though: utilizing this in software
isn't as easy as you might think!  The fork+exec + startup sequences
needed to be studied quite carefully to ensure the newly-executed
child doesn't ask for more than the parent's execpromises.  In my
experiments such a circumstance is exceedingly common, so the problem
is eased by introducing a new pledge feature which allows pledge
violations to return ENOSYS or such rather than killing the process.
This feature also needs to be used with great caution (especially in
privileged programs) because programs which fail to observe errors may
continue operating forward very incorrectly; you've lost the ability
to catch it failing, and provide care by fixing the problem.

The other is pledgepaths.  The semantics are still being tuned a bit.
Before the first call to pledge() in a process, one can pledgepath()
directories.  Then later after pledge(), file access operations only
work if the traversal of the path crosses one of those pre-declared
directories (but better make sure you don't move a directory, because
the kernel remembers and reasons about the vnode of the directory
rather than the path).  Something similar is being worked on for files,
but we are still adjusting that, as well as a flag parameter for the
pledgepath() call which may constrain the operations done on such files.
As such, pledgepath() will become a filesystem containment mechanism
unlike chroot() because paths will still be based upon true /.