docs: mention risk of SUID binaries and also firejail-users(5)

On the introduction of firejail(1), mention the main risk of SUID
binaries and that by default, only trusted users should be allowed to
run firejail (and how to accomplish that).

Note: The added comment line is completely discarded (so there is no
extraneous blank line); see groff_man(7) for details.

Suggested by @emerajid on #5288.

Relates to #4601.

1 files changed, 11 insertions, 0 deletions

diff --git a/src/man/firejail.txt b/src/man/firejail.txt
index 087d1c85a..531bb6138 100644
--- a/src/man/firejail.txt
+++ b/src/man/firejail.txt
@@ -67,6 +67,17 @@ Firejail allows the user to manage application security using security profiles.
 Each profile defines a set of permissions for a specific application or group
 of applications. The software includes security profiles for a number of more common
 Linux programs, such as Mozilla Firefox, Chromium, VLC, Transmission etc.
+.\" TODO: Explain the security/usability tradeoffs from #4601.
+.PP
+Firejail is currently implemented as an SUID binary, which means that if a
+malicious or compromised user account manages to exploit a bug in Firejail,
+that could ultimately lead to a privilege escalation to root.
+To mitigate this, it is recommended to only allow trusted users to run firejail
+(see firejail-users(5) for details on how to achieve that).
+For more details on the security/usability tradeoffs of Firejail, see:
+.UR https://github.com/netblue30/firejail/discussions/4601
+#4601
+.UE
 .PP
 Alternative sandbox technologies like snap (https://snapcraft.io/) and flatpak (https://flatpak.org/)
 are not supported. Snap and flatpak packages have their own native management tools and will