Just a reminder that seccomp is available to all the applications, and if you include it in the app itself, you can limit the privileges much better than firejail can. For example apps don't usually need to read config, or don't need to open new listening sockets once their initialised. This can be easily done in the app, but not by firejail.
I'm quite disappointed projects don't integrate that functionality upstream. The only popular one I know of is chrome.
openbsd has a simple api, pledge() [0]. The seccomp APIs are more powerful, but also more difficult to use. Are there simplified wrappers available for them that provide something akin to pledge that could just be sprinkled into your application startup?
There's libseccomp which provides nice interface, but still at syscall level. You can't easily implement pledge interface on seccomp, because you can't dereference pointers in BPF. So if you want to support both, you'll have to do a bit of rearchitecture anyway. But it's not very hard.
Mostly a: implement was you know, (see if all works, add missing calls, repeat)+ process
I am glad to see this on front page of HN! Of course I use it mainly for additional web browser sandboxing, but it has some useful "side-features" that are really convenient - namely overlayfs/overlaytmpfs. This is great when I test new software and I don't want to clutter my home directory.
Disclaimer: I am just a satisfied user :)
EDIT: Looks like it now fully supports X11 sandboxing.
At Wikimedia, we are using firejail to lock down services. We encountered some bugs in older versions, but those have since been fixed. Overall, it has been working fairly well for us.
We use firejail to implement the itch.io sandbox on Linux: https://itch.io/docs/itch/using/sandbox/linux.html - it's a refreshing alternative to the usual suspects, a lot more similar to macOS's sandbox-exec.
I use and enjoy firejail. I use it instead of grsecurity's RBAC on my desktop systems for basic sandboxing with minimal fuss on Arch Linux, where at least when I was setting things up, AppArmor needs a lot of manual configuration.
The degree of security provided depends on the configuration passed to firejail for a particular program.
If you shove something into a completely isolated tmpfs and disable most syscalls it's probably secure.
If you relax the configurations then the content may be able to use ipc mechanisms to talk to things outside the sandbox or modify the filesystem in a way that will result in an exploit at some later point in time.
Yes, but there's a difference between an exploit being the sandbox not working as intended and the sandbox being used for a purpose for which is not intended.
Am I correct in thinking that this approach could lead to new vulnerabilities? Since firejail is SUID, a bug in it could lead to execution of code in root context, while the original app would have run under user context only, right?
Apart from that, I am not sure how firejail limits the app if there is no manual config? I must have misunderstood the About page...
> this approach could lead to new vulnerabilities?
Yes. The first line of the article ("a SUID program that reduces the risk of security breaches") should be enough to raise a quizical eyebrow from security-minded users but overwhelming positive commentary I've seen elsewhere (lwn?) has not mentioned this.
Some of the obvious holes (eg "mount a tmpdir on any mount point") have now apparently been closed but I haven't been back to it for a while. Early releases did everything euid==0... It certainly needs more pairs of eyes.
OTOH the largest attack surface presented by a typical single-user Linux box is probably the browser and not an unprivileged local user looking for escalations (assuming: firejail drops privs perfectly and an attacker cannot trigger a vulnerability in SUID firejail from the application that it invoked). So could be that's a reasonable trade off for some folks.
> like the idea though
I agree, the feature set is nice but it needs some more basic TLC. "Security products do not necessarily make systems more secure" </rant>
Many of the things firejail does can be achieved without suid by using user namespaces instead.
But not all of them. E.g. the setup of network bridges between the host namespace and the jail namespace needs root, or at least cap_net_admin. Docker&co. need a suid broker for the same reason.
I'm quite disappointed projects don't integrate that functionality upstream. The only popular one I know of is chrome.