
Firejail – security sandbox - simonpure
https://firejail.wordpress.com/
======
viraptor
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.

~~~
the8472
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....](https://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.html)

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

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

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

~~~
Scaevolus
What made you choose Firejail over alternatives like Docker?

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

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

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

------
fasterthanlime
We use firejail to implement the itch.io sandbox on Linux:
[https://itch.io/docs/itch/using/sandbox/linux.html](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.

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

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

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

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

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

~~~
asdfadr1344kk
Completely.

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

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

------
Drdrdrq
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. :)

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

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

~~~
zwp
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!

------
X86BSD
_facepalm_

Throw another tire on the Linux tire fire.

------
SFJulie
Wordpress blog to talk about security?

