Firejail – security sandbox | Hacker News Reader

Firejail – security sandbox

firejail.wordpress.com

128 pointssimonpure32 comments

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?

[0] https://www.openbsd.org/papers/hackfest2015-pledge/mgp00001....

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

The Wikipedia page for seccomp lists some other projects, most notably Firefox, OpenSSH and Tor.

https://en.wikipedia.org/wiki/Seccomp

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.

What made you choose Firejail over alternatives like Docker?

Or maybe even more appropriate: AppArmor (or SELinux).

Firejail can be invoked and configured by normal unprivileged users. Apparmor requires root for creating and installing new profiles.

The new tools are being invented because the old tools suck.

SELinux is terrible from a UX standpoint

Docker is not for secure sandboxing, afaik you can easily escape and get root.

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.

This says that anyone with a 3.x kernel can run this, but note that seccomp filters were introduced in 3.5.

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.

Is this a safe enough sandbox that you could execute whatever an arbitrary url sends you without malicious content being able to break your machine?

There couldn't be any guarantee for "whatever" and "arbitrary", you know.

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.

Everything is exploitable to some extent.

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.

Would be useful to see how different are its ways than those of sandstorm.io

Completely.

I'm glad to see another project adopting appimage. I'm really hoping this will be the new standard deployment tool.

Sadly, it awful for security, since updating system libraries/packages won't update any potential vulnerable libraries bundled inside the appimage.

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.

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...

EDIT: like the idea though. :)

a) The app will still run as the specified user:

    $ firejail whoami
    [...]
    <your user>
    [...]

Firejail ships a bunch of standard profiles for common programs, e.g. Firefox, VLC, ...

Thanks for clarifying both points, will try it out. Keep up the good work!

> 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>

This only applies to the non-sandboxed context. The sandboxed apps don't have access to SUID binaries by default.

That'll certainly help keep the wolves at bay (though I still will not install firejail 4755...).

~1000 commits since I last looked at firejail, keep up the good work!

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.

Bubblewrap is a similar tool which carefully handles it's setuid responsibilities:

https://github.com/projectatomic/bubblewrap#related-project-...

facepalm

Throw another tire on the Linux tire fire.

Wordpress blog to talk about security?

Reply on news.ycombinator.com