4 ms·

Because Theo is right, having to write programs to observe programs is insane. While spender is wrong for multiple reasons. Such as that /var is mounted nosuid

by glass- 11y ago

Because Theo is right, having to write programs to observe programs is insane. While spender is wrong for multiple reasons. Such as that /var is mounted nosuid on OpenBSD by default so their hypothetical "httpd chmod'ing to setuid" doesn't work ("nix" points this out to them but isn't aware of OpenBSD's defaults in this area). The other reason is they are decrying the whole system because of a fairly weak attack scenario (requires a local user account) and it's not like that attack isn't possible now, so while tame() doesn't protect against that specific thing it protects against others but spender is just saying nope, it doesn't protect against this specific scenario therefore it's useless. Also if you keep reading spender's commenters they go on to claim OpenBSD's devs are delusional plagiarists so "vendetta" does seem appropriate.

_yy 11y ago
Spender's point is that a capabilities-based approach does not really work for real-world scenarios, and he probably has a point. The setuid thing was more an example as I understood it. While Spender's criticism isn't usually very diplomatic, he's often right. Here's an example, this is QEMU's seccomp whitelist: http://git.qemu.org/?p=qemu.git;a=blob_plain;f=qemu-seccomp.c;hb=HEAD http://git.qemu.org/?p=qemu.git;a=blob_plain;f=qemu-seccomp.... As you can see, it's mostly worthless since QEMU has to do lots of potentially-dangerous operations by design (even reading/writing to raw devices). A proper mandatory access control framework actually restricts which device files it can access, for example - as implemented in the AppArmor/SELinux sVirt drivers. Theo's approach is similarly flawed.
- vezzy-fnord 11y ago
  capabilities-based approach tame() isn't a capabilities-based approach. Don't confuse POSIX capabilities with actual capability-based security. The former hijacked an existing term to refer to a different thing. It's pretty obviously a limited API, but it also makes privilege dropping absolutely trivial. Which is the point.

by glass- 11y ago

_yy 11y ago

Spender's point is that a capabilities-based approach does not really work for real-world scenarios, and he probably has a point. The setuid thing was more an example as I understood it. While Spender's criticism isn't usually very diplomatic, he's often right. Here's an example, this is QEMU's seccomp whitelist: http://git.qemu.org/?p=qemu.git;a=blob_plain;f=qemu-seccomp.c;hb=HEAD http://git.qemu.org/?p=qemu.git;a=blob_plain;f=qemu-seccomp.... As you can see, it's mostly worthless since QEMU has to do lots of potentially-dangerous operations by design (even reading/writing to raw devices). A proper mandatory access control framework actually restricts which device files it can access, for example - as implemented in the AppArmor/SELinux sVirt drivers. Theo's approach is similarly flawed.

vezzy-fnord 11y ago
capabilities-based approach tame() isn't a capabilities-based approach. Don't confuse POSIX capabilities with actual capability-based security. The former hijacked an existing term to refer to a different thing. It's pretty obviously a limited API, but it also makes privilege dropping absolutely trivial. Which is the point.