Change Details

This is a proof of concept implementation of some changes to how Capsicum handles path names. It's in some ways similar to D38351 by Val Packett, but implemented quite differently. The way this works now is that absolute path lookups are prohibited, and relative are only allowed with an explicitely provided directory descriptor. The works it works with the patch is that both are allowed, but only if the process - or its ancestor - called fchdir(2) and fchroot(2) to set the descriptors the (nowly allowed) lookups are relative to. Calling cap_enter(2) clears both descriptors again. Another thing that changes is that binaries in capability mode are now allowed to execute other binaries. With D44372 one can run sh(1) this way. There is a (pretty terrible, and obviously temporary) hack to chroot(8) utility to make it possible to try it "by hand": $ chroot -Cdn 5 /bin/sh 5< / Regarding the Capsicum security model, I believe the lookup change doesn't change it. The directory descriptors for lookups still need to be provided by the process, like before; it's just that now it can ask the kernel to use them for absolute and relative lookups instead of having to explicitly pass them to APIs like openat(2).

This is a proof of concept implementation of some changes to how Capsicum handles path names. It's in some ways similar to D38351 by Val Packett, but implemented quite differently. The primary motivation is to make it possible to execute binaries in capability mode from the start, without having to trust them. The way this works now is that absolute path lookups are prohibited, and relative are only allowed with an explicitely provided directory descriptor. The works it works with the patch is that both are allowed, but only if the process - or its ancestor - called fchdir(2) and fchroot(2) to set the descriptors the (nowly allowed) lookups are relative to. Calling cap_enter(2) clears both descriptors again. There is a (pretty terrible, and obviously temporary) hack to chroot(8) utility to run binaries in capability mode "by hand": $ chroot -Cdn 5 /bin/sh 5< / Regarding the Capsicum security model, I believe the lookup change doesn't change it. The directory descriptors for lookups still need to be provided by the process, like before; it's just that now it can ask the kernel to use them for absolute and relative lookups instead of having to explicitly pass them to APIs like openat(2). Sponsored by: Innovate UK

This is a proof of concept implementation of some changes to how Capsicum handles path names. It's in some ways similar to D38351 by Val Packett, but implemented quite differently. The primary motivation is to make it possible to execute binaries in capability mode from the start, without having to trust them. The way this works now is that absolute path lookups are prohibited, and relative are only allowed with an explicitely provided directory descriptor. The works it works with the patch is that both are allowed, but only if the process - or its ancestor - called fchdir(2) and fchroot(2) to set the descriptors the (nowly allowed) lookups are relative to. Calling cap_enter(2) clears both descriptors again. Another thing that changes is that binaries in capability mode areThere is a (pretty terrible, and obviously temporary) hack now allowed to execute other binaries. With D44372 one can run sh(1) this way. There is a (pretty terrible, and obviously temporary) hack to chroot(8) utility to make it possible to try itrun binaries in capability mode "by hand": $ chroot -Cdn 5 /bin/sh 5< / Regarding the Capsicum security model, I believe the lookup change doesn't change it. The directory descriptors for lookups still need to be provided by the process, like before; it's just that now it can ask the kernel to use them for absolute and relative lookups instead of having to explicitly pass them to APIs like openat(2). Sponsored by: Innovate UK