github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #594] Document how much secure it really is #420

New issue

Closed

opened 2026-05-05 05:49:30 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 05:49:30 -06:00

Owner

Originally created by @vporton on GitHub (Jun 24, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/594

From the documentation and the manpage it is unclear how much safe the current version of Firejail is.

Suppose we deal with a deliberate hacker which wants make harm. Can the hacker do any harm if he is in the jail? If yes, which harm is possible?

This is the bug report about not enough documentation. Please edit the site and the manpage.

Originally created by @vporton on GitHub (Jun 24, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/594 From the documentation and the manpage it is unclear how much safe the current version of Firejail is. Suppose we deal with a deliberate hacker which wants make harm. Can the hacker do any harm if he is in the jail? If yes, which harm is possible? This is the bug report about not enough documentation. Please edit the site and the manpage.

gitea-mirror

2026-05-05 05:49:30 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 05:49:36 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jun 24, 2016):

G'day vporton. 😄
There's a saying in the Linux world: "Everything can be hacked, nothing is entirely secure, so aim for as much nothing as posible."
In other words, a deliberate hacker can cause harm in any environment. This is as true for firejail as for any other software or even OS.

Firejail is great because it greatly limits the damage an unprivileged hacker can cause. It also forbids many systemcalls, via a seccomp filter, that a privileged attacker could use. But as in everything else, it isn't foolproof and a dedicated attacker could manage to break out of firejail. From there, it's a matter of your system setup and your individual security, not firejail. :)
( @netblue30 or anyone else: please correct me if I'm wrong.)

On the other hand, firejail can have bugs just like any other programme. For example, about 6 months ago firejail underwent an external security audit that disclosed several vulnerabilities relating to SUID. These bugs were fixed with the 0.9.38 release. As another example, I found a way (that only applies to a small and specific subset of users) to break out of the jail. This too has been patched.

Now as regards to your particular request, it should be impossible to document how safe Firejail makes you. Security is a multi-faceted topic, and a lot of it rests squarely on the end-user's (i.e. your) shoulders. Firejail can't protect you from careless errors or malicious software that is not run in firejail, nor is it some sort of "superhero" that can rescue you from problems already existing on your system. What it can do, and do very well, is set up a reasonably secure jail to run untrusted applications in, just as the documentation currently says. 😉

Hope this helps!
Fred

@Fred-Barclay commented on GitHub (Jun 24, 2016): G'day vporton. :smile: There's a saying in the Linux world: "Everything can be hacked, nothing is entirely secure, so aim for as much nothing as posible." In other words, a deliberate hacker can cause harm in **any** environment. This is as true for firejail as for any other software or even OS. Firejail is great because it greatly limits the damage an unprivileged hacker can cause. It also forbids many systemcalls, via a seccomp filter, that a privileged attacker could use. But as in everything else, it isn't foolproof and a dedicated attacker could manage to break out of firejail. From there, it's a matter of your system setup and your individual security, not firejail. :) ( @netblue30 or anyone else: please correct me if I'm wrong.) On the other hand, firejail can have bugs just like any other programme. For example, about 6 months ago firejail underwent an external security audit that disclosed several vulnerabilities relating to SUID. **These bugs were fixed with the 0.9.38 release.** As another example, I found a way (that only applies to a small and specific subset of users) to break out of the jail. This too has been patched. Now as regards to your particular request, it should be impossible to document how safe Firejail makes you. Security is a multi-faceted topic, and a lot of it rests squarely on the end-user's (i.e. your) shoulders. Firejail can't protect you from careless errors or malicious software that is not run in firejail, nor is it some sort of "superhero" that can rescue you from problems already existing on your system. What it can do, and do very well, is set up a reasonably secure jail to run untrusted applications in, just as the documentation currently says. :wink: Hope this helps! Fred

gitea-mirror commented

2026-05-05 05:49:38 -06:00

Author

Owner

@vporton commented on GitHub (Jun 24, 2016):

I am writing a program which (among other things) will download from
the Web interpreted code (like Python) transforming between different
file formats and run it in a jail on our server, so that our server
could transform a file format through several intermediary stages,
where every stage of transformation is an arbitrary interpreted code
from the Web.
Maybe, my methodology is wrong and I should think that my server will
be crashed by hackers too often to be practically useful?
Or should I continue?
On Fri, 2016-06-24 at 11:55 -0700, Fred Barclay wrote:

G'day vporton. 😄
There's a saying in the Linux world: "Everything can be hacked,
nothing is entirely secure, so aim for as much nothing as posible."
In other words, a deliberate hacker can cause harm in any
environment. This is as true for firejail as for any other software
or even OS.
Firejail is great because it greatly limits the damage an
unprivileged hacker can cause. It also forbids many systemcalls, via
a seccomp filter, that a privileged attacker could use. But as in
everything else, it isn't foolproof and a dedicated attacker could
manage to break out of firejail. From there, it's a matter of your
system setup and your individual security, not firejail. :)
( @netblue30 or anyone else: please correct me if I'm wrong.)
On the other hand, firejail can have bugs just like any other
programme. For example, about 6 months ago firejail underwent an
external security audit that disclosed several vulnerabilities
relating to SUID. These bugs were fixed with the 0.9.38 release. As
another example, I found a way (that only applies to a small and
specific subset of users) to break out of the jail. This too has been
patched.
Now as regards to your particular request, it should be impossible to
document how safe Firejail makes you. Security is a multi-faceted
topic, and a lot of it rests squarely on the end-user's (i.e. your)
shoulders. Firejail can't protect you from careless errors or
malicious software that is not run in firejail, nor is it some sort
of "superhero" that can rescue you from problems already existing on
your system. What it can do, and do very well, is set up a reasonably
secure jail to run untrusted applications in, just as the
documentation currently says. 😉
Hope this helps!
Fred
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@vporton commented on GitHub (Jun 24, 2016): I am writing a program which (among other things) will download from the Web interpreted code (like Python) transforming between different file formats and run it in a jail on our server, so that our server could transform a file format through several intermediary stages, where every stage of transformation is an arbitrary interpreted code from the Web. Maybe, my methodology is wrong and I should think that my server will be crashed by hackers too often to be practically useful? Or should I continue? On Fri, 2016-06-24 at 11:55 -0700, Fred Barclay wrote: > G'day vporton. 😄 > There's a saying in the Linux world: "Everything can be hacked, > nothing is entirely secure, so aim for as much nothing as posible." > In other words, a deliberate hacker can cause harm in any > environment. This is as true for firejail as for any other software > or even OS. > Firejail is great because it greatly limits the damage an > unprivileged hacker can cause. It also forbids many systemcalls, via > a seccomp filter, that a privileged attacker could use. But as in > everything else, it isn't foolproof and a dedicated attacker could > manage to break out of firejail. From there, it's a matter of your > system setup and your individual security, not firejail. :) > ( @netblue30 or anyone else: please correct me if I'm wrong.) > On the other hand, firejail can have bugs just like any other > programme. For example, about 6 months ago firejail underwent an > external security audit that disclosed several vulnerabilities > relating to SUID. These bugs were fixed with the 0.9.38 release. As > another example, I found a way (that only applies to a small and > specific subset of users) to break out of the jail. This too has been > patched. > Now as regards to your particular request, it should be impossible to > document how safe Firejail makes you. Security is a multi-faceted > topic, and a lot of it rests squarely on the end-user's (i.e. your) > shoulders. Firejail can't protect you from careless errors or > malicious software that is not run in firejail, nor is it some sort > of "superhero" that can rescue you from problems already existing on > your system. What it can do, and do very well, is set up a reasonably > secure jail to run untrusted applications in, just as the > documentation currently says. 😉 > Hope this helps! > Fred > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or mute the thread.

gitea-mirror commented

2026-05-05 05:49:39 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jun 24, 2016):

I don't know if you should continue, you'll have to decide if the benefits outweigh the risks. That's a highly personal decision. 😁

Personally, if you use good security precautions (including but not limited to using firejail) then I would proceed. But I don't understand your project very much so take that with a grain of salt.

@Fred-Barclay commented on GitHub (Jun 24, 2016): I don't know if you should continue, you'll have to decide if the benefits outweigh the risks. That's a highly personal decision. :grin: Personally, if you use good security precautions (including but not limited to using firejail) then I would proceed. But I don't understand your project very much so take that with a grain of salt.

gitea-mirror commented

2026-05-05 05:49:41 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jun 24, 2016):

@vporton : If I understand correctly, you're not sure if you can trust the interpreted code you're running, and you're worried about whether that code can cause temporary or permanent harm to your server.

To that, I would say that you should place restrictions on what capabilities the code has (i.e. what kinds of things it can do) and let your users know of those restrictions. Then, enforce those restrictions using a combination of classic Linux permissions, firejail, and possibly SELinux or AppArmor.

Firejail can be an integral tool, but I don't know that you can rely solely on it, just like you can't rely solely on AppArmor or SELinux or Linux permissions or any other tool, especially since this is a public-facing server that is supposed to run user-submitted code.

@chiraag-nataraj commented on GitHub (Jun 24, 2016): @vporton : If I understand correctly, you're not sure if you can trust the interpreted code you're running, and you're worried about whether that code can cause temporary or permanent harm to your server. To that, I would say that you should place restrictions on what capabilities the code has (i.e. what kinds of things it can do) and let your users know of those restrictions. Then, enforce those restrictions using a combination of classic Linux permissions, firejail, and possibly SELinux or AppArmor. Firejail can be an integral tool, but I don't know that you can rely solely on it, just like you can't rely solely on AppArmor or SELinux or Linux permissions or any other tool, _especially_ since this is a public-facing server that is supposed to run user-submitted code.

gitea-mirror commented

2026-05-05 05:49:43 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 26, 2016):

@vporton : Security is very difficult to explain and impossible to measure. In the documentation I just describe the technologies I am using for sandboxing.

@netblue30 commented on GitHub (Jun 26, 2016): @vporton : Security is very difficult to explain and impossible to measure. In the documentation I just describe the technologies I am using for sandboxing.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#420

No description provided.

Rows
Columns