Why block /usr/? Maybe block more userdata instead?

[kolAflash]

I've wondered if it's really helpful to block parts of /usr/.
Question: Which problem or threat model is counteracted by blocking /usr/?

Instead Firejail should maybe block additional directories where (writeable) userdata is stored.

 

Why stop blocking /usr

This includes questioning, why Firejail blocks many interpreters. Although not all interpreters. bash for example often isn't blocked.
https://github.com/netblue30/firejail/blob/072c15b8bfc1eca0368071c3d798b29459686c04/etc/inc/disable-interpreters.inc
Some other examples of blocks below /usr/ which I'm questioning.
disable-common.inc (line 229 and on-wards)
Badly behaving programs don't need gcc, they could just include their own compiler.
disable-devel.inc (line 68 and on-wards)

 

/usr/ isn't writeable for anyone but root, so no need to discuss that. And usually /usr/ contains only files publicly available from the Internet. So no information leakage possible when running without --net=none. (maybe except for /usr/local/)

So then why block /usr/? If a program is behaving really badly, it can just bring things like a Python interpreter itself. It only needs the possibility to create files and mark them executable.

The only thing that came to my mind, to block parts of /usr/, are setuid binaries in /usr/. JUST MAYBE a Linux distribution could ship some setuid binary which allows escaping a sandbox by using root permissions. At least if that's possible for root. But I know of none such binary shipped under /usr/ by common Linux distributions.

I've just had a time consuming issue, where Wine was missing /usr/bin/python3*.

 

Block (writeable) userdata instead

Instead I'm proposing, to block more directories containing writeable userdata.

At least from my perspective, a main reason for using Firejail is, to ensure badly behaving programs can't leak, modify or delete user data. Because of that, I'd additionally block access to this directories (or put empty mounts there) for most profiles:

• /tmp/ # --private-tmp
• /srv/ # for example data you might want to server to HTTP authorized users, but not to anyone
• /var/ # may contain a lot of private data like all kinds of long living /var/tmp files (/tmp/ is for short lived ones), mails, ...
• /run/ # except for /run/resolvconf and the sockets of X11, Wayland, Pulseaudio and Pipewire

 

Here's an issue which handles this topic in detail:

• add profile with only /bin /sbin /usr + partly /etc and optionally Wayland, X11, DRM and audio #6742
  I'd not use --private-dev and block /opt/ in general, as described in that issue.

Relates to:

• wine: blacklisting python prevents gstreamer initialization #6762

[rusty-snake]

Which threat model is counteracted by (some) firejail profiles?

paranoia and theater

why Firejail blocks many interpreters.

Deny executing of arbitrary code / W^X.

Interpreters that perform executability check can be removed in the future IMHO.

Although not all interpreters.

Enumerating badness will never produce a complete list. If you knew missing interpreters, open a PR and add them.

bash for example often isn't blocked.

Shells are handled by disable-shell.inc. If the program requires (ba)sh, we obviously need to allow it.

VeraCrypt

⬆️ paranoia and theater

/usr/ isn't writeable for anyone but root, so no need to discuss that.

• Historically some parts of /usr like /usr/games are group writable.
• On immutable systems /usr is read-only (with exception of /usr/local).
• No matter what, there is read-only /usr.

So then why block /usr/?

• ⬆️ paranoia and theater
• Blocking post-exploit hooks

It only needs the possibility to create files and mark them executable.

Something you always want to block.

The only thing that came to my mind, to block parts of /usr/, are setuid binaries in /usr/.

nosuid / no-new-privs

[kolAflash]

Which threat model is counteracted by (some) firejail profiles?

paranoia and theater

As those aren't recognized programming guidelines, I'd count it as an argument for not blocking /usr/ ;-)

 

 

why Firejail blocks many interpreters.

Deny executing of arbitrary code / W^X.

Interpreters that perform executability check can be removed in the future IMHO.

Including -e or -c command line parameters like bash -c 'echo foo' or python3 -c 'print("bar")'.

Although not all interpreters.

Enumerating badness will never produce a complete list. If you knew missing interpreters, open a PR and add them.

bash for example often isn't blocked.

Shells are handled by disable-shell.inc. If the program requires (ba)sh, we obviously need to allow it.

As long as one interpreter is allowed, all can be allowed. At least if the already allowed interpreter is not just turing complete but allows for making arbitrary (sys)calls.

I'm not completely sure about bash. But my gut says, if bash is allowed any other interpreter can be allowed too. No need to debug for hours, to find out which one is really needed by which program.

I don't really see a way to close the "executable code door" for most Firejail profiles. Lets better focus on which files a jailed program can read / write.

 

 

VeraCrypt

⬆️ paranoia and theater

Mostly wanted to link the disable-common.inc file for the thinks under /usr/ blocked below the linked line. That line just happened to point to the line with VeraCrypt. But other things like /usr/bin/apt or /usr/bin/upower, listed in that file, don't have to be blocked either. You can do nothing bad using them, except you're root.

/usr/ isn't writeable for anyone but root, so no need to discuss that.

* Historically some parts of `/usr` like `/usr/games` are group writable.

Very interesting point!
OK, then I'd at least make /usr/games explicitly read-only. Maybe even completely, block access, because it may contain user data which should not be leaked.

 

It only needs the possibility to create files and mark them executable.

Something you always want to block.

The only thing that came to my mind, to block parts of /usr/, are setuid binaries in /usr/.

nosuid / no-new-privs

I guess nodev can be applied in pretty much all cases.

nosuid may be needed if a program needs some setuid binary from /usr/bin/.

noexec may be a more difficult question. And in most cases where interpreters are needed, it doesn't make sense at all.

I actually use --seccomp which includes --nonewprivs for most of my profiles and it works just fine. So it may be a good idea to add this as default, so programs can't escape Firejail using setuid binaries in /usr/.

[rusty-snake]

nonewprivs default

There are already ways to opt-in to that.

firejail/etc/firejail.config

Line 49 in 072c15b

# force-nonewprivs no

firejail/configure

Line 1430 in 072c15b

--enable-force-nonewprivs

Although they are not just default but always-on. The thread model here is also no sandbox escape but privileged escalation by an unprivileged user who uses firejail to modify the environment and the execute a suid program (e.g. say firejail would allow to create files beneath /etc with private-etc because it is an tmpfs. Then an unprivileged use could use private-etc foo, create a /etc/sudoers and sudo itself to root).

[kmk3]

This includes questioning, why Firejail blocks many interpreters. Although
not all interpreters. bash for example often isn't blocked.

In many cases the program itself does not need a shell at all, but in one or
more distributions the target executable in /usr/bin happens to be a shell
script wrapper that sets some variables and then calls the main program.

If the filename of the shell wrapper and the main program differ, then we can
create a profile for the wrapper that allows shells and one for the main
program that doesn't.

Although not all interpreters.

Enumerating badness will never produce a complete list. If you knew missing
interpreters, open a PR and add them.

bash for example often isn't blocked.

Shells are handled by disable-shell.inc. If the program requires
(ba)sh, we obviously need to allow it.

As long as one interpreter is allowed, all can be allowed. At least if the
already allowed interpreter is not just turing complete but allows for making
arbitrary (sys)calls.

I think the point of these includes is not about whether there technically
might exist some interpreter somewhere on the system for some given language
that is turing-complete, but about what is the cost/benefit of using it. For
example, how likely is it that someone is going to bother writing, testing and
using the same code in multiple different languages just in case the other
interpreters are not available? Especially if in the vast majority of cases
that would likely be redundant?

I'm not completely sure about bash. But my gut says, if bash is allowed any
other interpreter can be allowed too. No need to debug for hours, to find out
which one is really needed by which program.

I don't really see a way to close the "executable code door" for most
Firejail profiles. Lets better focus on which files a jailed program can read
/ write.

If you don't care about blocking interpreters and shells, you can just add the
following to globals.local:

ignore include disable-interpreters.inc
ignore include disable-shell.inc