|
|
|
|
|
|
by Arch-TK
974 days ago
|
|
|
I think realistically most of the things people seriously care about pledging are complex application and server software so yes the point is you run into problems trying to pledge things. Obviously you can come up with the minimum set of things you can pledge pretty quickly to get things working, but that doesn't guarantee they will keep working. And you can also be very broad, but there's a point at which that doesn't gain you much in terms of security (or as much as you may have set out to gain). This reminds me of a situation where I tried to use firejail to isolate this proprietary piece of software, I ran firejail in the "auto-generate-something-sensible" mode and then tried running it in that profile. It would just randomly break at that point. I never quite figured this out due to lack of time. I was expecting to be able to roll with an auto-generated profile at first and tighten it later, the actual end result was there was no profile at all. The other issue you run into is getting things which work sometimes and then stop working randomly. Especially when it's a large graphical application. It will do something strange when you click a specific button and crash. Now you are annoyed, probably not in the mood to debug this, so maybe you make a note for later. Now you have to recreate the issue under strace, figure out what you need to pledge now, and repeat. Yes, if you're trying to pledge ls, it's pretty easy. If you're trying to pledge anything non-trivial (i.e. anything which would _really_ benefit from these security restrictions) you end up iterating a lot. It's not very fun. |
|
|
This is exactly the point where the experience between pledge and e.g. firejail drastically diverges. The entire reason why pledge is so nice, is because it assumes source access. You can use execpromises to "jail" something you don't control, but the set of promises is always going to be unnecessarily broad, as even the sanest software out there often needs a tiny backflip before it can enter the main loop. Source access also means you have the means to investigate what exactly went wrong, or to actually fix the stupidity (rather than broadening the privileges).
The amount of things you can do to a proprietary blob to contain it is pretty limited - by definition! I think using a container/VM to completely isolate it would be a better call.
> It will do something strange when you click a specific button and crash. Now you are annoyed, probably not in the mood to debug this, so maybe you make a note for later.
When you do pledge("... error", ...), the app will get errors from disallowed syscalls, rather than a SIGABRT, which is useful when you're not sure. Mis-handling an error can still blow things up, but that's a sign that maybe the overall code quality is not great. In any case, yes you do basically need to be running the application under ktrace (/strace) for as long as you're not certain.
Actually what I think would be great is a "tracing mode" for pledge, where the kernel reports violations (PID + syscall with parms + suggested promise), maybe even takes a core snapshot at each violation, but otherwise doesn't hurt the application.
> If you're trying to pledge anything non-trivial (i.e. anything which would _really_ benefit from these security restrictions) you end up iterating a lot.
Indeed, but that's a curse of complex software, not a shortcoming of pledge itself. OpenBSD introduced pledge and contained almost the entire base system within a single release cycle.
I personally think that as an industry, software is going through a crisis of explosive complexity. I see efforts like pledge as a mirror, through which that complexity stares back at us, in all of its ugliness. Blaming the mirror does not address the issue.