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. :)
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-...
$ firejail whoami
[...]
<your user>
[...]
Firejail ships a bunch of standard profiles for common programs, e.g. Firefox, VLC, ...