That was my question as well. Capsicum was written after discussing the requirements that Apple had with their engineers and provides the abstract model in the kernel that Apple eventually builds at the high-level layer on top of some complex policies that hit impedance mismatches with the MAC framework in a few exciting places. They’ve invested enough in it now that porting Capsicum to XNU and Seatbelt is probably not worth the effort, but if you want to end up with something like the macOS / iOS sandboxing infrastructure and can start from scratch, please start with Capsicum and not the MAC framework!
eBPF is horrible for security. Capsicum can’t really be used in any complex application. At least, not without using a library like libcasper that 100% negates use of Capsicum.
If an attacker can ROP, an attacker can also modify data. Perhaps overwrite a buffer that would tell libcasper to open /bin/sh, then ret2casper, then fexecve(new fd from casper).
Think like an attacker. Don’t think like an engineer.
But whatever requests to casper the attacker has created in the application, casper would not give the application anything not allowed by casper’s policy. Casper provides very specific services with very specific restrictions, not arbitrary opening of anything.
escaping_from_freebsd_bhyve.html
I’ve seen it. Yeah, no shit, if you have a capability to /dev/mem, you get to do anything you want with memory. But that’s basically only a concern for things like hypervisors. Normal applications running as a regular user don’t get access to /dev/mem even without sandboxing.
Not arbitrary, filtered by a policy. You can restrict the allowed addresses/ports/etc. however much you want using cap_net_limit and these restrictions can’t be rolled back.
I must’ve misunderstood, then. Because I thought it was all self-contained in libcasper, which just spun off pre-Capsicumized threads and did the work there. My apologies.
I might look at using this as a basis for grsecurity rbac in HardenedBSD.
Unrelated to the OP, I wonder if you have any thoughts on implementing pledge(2) and/or unveil(2) in HardenedBSD?
Some work is being/has been done on that front by a HardenedBSD community member. Nothing official as of yet. :)
Why sandbox programs via MAC when capsicum exists? >_<
If libc hooks aren’t enough for sandboxing existing programs from the outside for some reason (works well for me), there’s now work on eBPF for hooking the syscalls in the kernel.
That was my question as well. Capsicum was written after discussing the requirements that Apple had with their engineers and provides the abstract model in the kernel that Apple eventually builds at the high-level layer on top of some complex policies that hit impedance mismatches with the MAC framework in a few exciting places. They’ve invested enough in it now that porting Capsicum to XNU and Seatbelt is probably not worth the effort, but if you want to end up with something like the macOS / iOS sandboxing infrastructure and can start from scratch, please start with Capsicum and not the MAC framework!
eBPF is horrible for security. Capsicum can’t really be used in any complex application. At least, not without using a library like libcasper that 100% negates use of Capsicum.
How does use of a broker process that passes capabilities “100% negate” anything?!?!
ret2casper
How does it matter? The casper processes will never pass the sandboxed process anything that’s not allowed by their policy.
If an attacker can ROP, an attacker can also modify data. Perhaps overwrite a buffer that would tell libcasper to open /bin/sh, then ret2casper, then fexecve(new fd from casper).
Think like an attacker. Don’t think like an engineer.
If you think there’s vulnerabilities in casper that can be exploited via requests, go find and fix them ;)
Also,
fexecve(/bin/sh fd)would not do much. The shell would still have the same capabilities!It’s not about vulnerabilities in casper, it’s about vulnerabilities in the application itself. Manipulating data to do the bidding of the attacker.
As for breaking out of a Capsicum sandbox: http://phrack.org/papers/escaping_from_freebsd_bhyve.html
But whatever requests to casper the attacker has created in the application, casper would not give the application anything not allowed by casper’s policy. Casper provides very specific services with very specific restrictions, not arbitrary opening of anything.
I’ve seen it. Yeah, no shit, if you have a capability to
/dev/mem, you get to do anything you want with memory. But that’s basically only a concern for things like hypervisors. Normal applications running as a regular user don’t get access to/dev/memeven without sandboxing.The point of casper is to get around Capsicum’s restrictions. Take https://svnweb.freebsd.org/base?view=revision&revision=364276 for example.
Using the cap_net libcasper service allows an application to be able to create arbitrary sockets again.
Not arbitrary, filtered by a policy. You can restrict the allowed addresses/ports/etc. however much you want using
cap_net_limitand these restrictions can’t be rolled back.That policy lives in the same address space as the victim process, right?
Of course not, why would it be?!
I must’ve misunderstood, then. Because I thought it was all self-contained in libcasper, which just spun off pre-Capsicumized threads and did the work there. My apologies.
I’m like 99.9% sure cap mode cannot be per thread, it’s only per process.