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.
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.
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.
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.
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.
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.
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
34 comments
[ 0.22 ms ] story [ 100 ms ] threadDisclaimer: I am just a satisfied user :)
EDIT: Looks like it now fully supports X11 sandboxing.
Reducing the risk of security breaches by introducing another vector of attack (ie. another SUID program) ? Really ?
SELinux is terrible from a UX standpoint
Everything is exploitable to some extent.
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.
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...
EDIT: like the idea though. :)
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>
~1000 commits since I last looked at firejail, keep up the good work!
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.
https://github.com/projectatomic/bubblewrap#related-project-...
I'm quite disappointed projects don't integrate that functionality upstream. The only popular one I know of is chrome.
[0] https://www.openbsd.org/papers/hackfest2015-pledge/mgp00001....
Mostly a: implement was you know, (see if all works, add missing calls, repeat)+ process
https://en.wikipedia.org/wiki/Seccomp
It's very "easy-to-use", but brings back all these sort of issues which we'd fixed so long ago!
It's doubly harmful when we're talking about a software that's security-related.
Throw another tire on the Linux tire fire.