4 ms·

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 conte

by Drdrdrq 10y ago

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

heinrich5991 10y ago
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, ...
- Drdrdrq 10y ago
  Thanks for clarifying both points, will try it out. Keep up the good work!
- deleted 10y ago
  [deleted]
zwp 10y ago
> 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 10y ago
  This only applies to the non-sandboxed context. The sandboxed apps don't have access to SUID binaries by default.
  - zwp 10y ago
    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!
- the8472 10y ago
  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.
- groks 10y ago
  Bubblewrap is a similar tool which carefully handles it's setuid responsibilities: https://github.com/projectatomic/bubblewrap#related-project-comparison-firejail https://github.com/projectatomic/bubblewrap#related-project-...

by Drdrdrq 10y ago

heinrich5991 10y ago

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

Drdrdrq 10y ago
Thanks for clarifying both points, will try it out. Keep up the good work!
deleted 10y ago
[deleted]

zwp 10y ago

> 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 10y ago
This only applies to the non-sandboxed context. The sandboxed apps don't have access to SUID binaries by default.
- zwp 10y ago
  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!
the8472 10y ago
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.
groks 10y ago
Bubblewrap is a similar tool which carefully handles it's setuid responsibilities: https://github.com/projectatomic/bubblewrap#related-project-comparison-firejail https://github.com/projectatomic/bubblewrap#related-project-...