41–47 of 47 posts
seccomp is heaps better than selinux, but still too overly complicated to be using in everyday production unless you're truly on the "refine and secure" path or dealing with high-stakes sandboxing.
Seccomp BPF is great. There was some recent issues due to IO_uring and extensible syscalls, but I believe for now, those issues are avoidable. I believe the next generation looks something like landlock ( https://docs.kernel.org/userspace-api/landlock.html ).
We had seccomp containers at Dropbox, and I remember Max Serrano helping me set that up with ReactServer :) Talented engineer, though I do remember that the jails were kind of a maintenance nightmare for the security team.
Earlier quoted context omitted.
nsjail author here (the original one, as the tool is also maintained by others), good job! Irrelevant nit: .proto files are protobuf definition files (like this one: https://github.com/google/nsjail/blob/master/config.proto ), a text representation of a specific protobuf contents is typically called (as per man clang-format): .textpb .pb.txt or .textproto - I use .config for examples distributed with nsjail, but it's…
Why not just use json?
However, I presume there are now JSON extensions that provide similar functionality?
Earlier quoted context omitted.
> When it comes to retrofitting something like pledge (or seccomp) into an existing application when you've not developed it and/or can't easily tell what syscalls are being called then it's always a nightmare. Quite the contrary. If the software in question has been written in a remotely sane way, adding some basic pledge restrictions is a matter of adding one line: pledge("stdio rpath whatever you need", NULL) - it…
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 does…
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.
Earlier quoted context omitted.
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 does…
> This reminds me of a situation where I tried to use firejail to isolate this proprietary piece of software [...]. 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…
I was never trying to imply that pledge had shortcomings.
I don't think we're disagreeing on anything here anyway.
The point I was making is that if you've got a large and complicated piece of software, which you didn't write yourself, which wasn't written with the intention of someone implementing a syscall filter for it, you will have a bad time. It's not quite as bad as if you have the code but it's always going to be pretty bad regardless.
I think pledge is great, and the rollout was really good (I use OpenBSD for my home router and for some other infrastructure). The OpenBSD developers were in the beneficial position that they are already familiar with the source code for their base userland, they already regularly audit and maintain security improvements for it. Also noteworthy is the fact that most of the OpenBSD base is (intentionally) not formed of extremely complex software.
It's pretty easy to apply seccomp to a process using systemd by adding SystemCallFilter= in its unit file. There's a reasonable set of permitted syscalls for general system processes, aptly called `@system-service`, but you can tweak that to suit your needs [1]. I generally use this, among other settings, to further lock down system services [2]. [1] https://www.freedesktop.org/software/systemd/man/latest/syst... [2]…