Add profiles for build-systems (/package-managers)

[rusty-snake]

Profiles: bunler, cargo (refactor), cmake (untested), make, meson, pip
All redirect to build-systems-common.profile

Other fixes:

• blacklist ${HOME}/.bundle
• blacklist ${HOME}/.cargo/* -> blacklist ${HOME}/.cargo
• blacklist /usr/lib64/ruby

You can now firejail make firejail 😆.

[kmk3]

While language-specific package managers tend to live in their own world,
general-purpose build-systems usually try to integrate with the system, and so
I'd expect more breakage from such profiles.

I'd make a separate PR for make, as it is very general purpose and another for
cmake/meson, as they are similar to autoconf, in the sense that they can be
used to run arbitrary commands to test for and configure things. If many
people end up using firejail with these tools, I'd expect more corner cases
than usual to be found (i.e.: compared to programs not related to development),
so being able to reference separate PRs on issues could help gauge the results
with timeline events.

[kmk3]

Considering that there is no standard path for this, if the includers of
build-systems-common.profile are ever enabled by default, I'd wager that there
would be many issues opened due to the whitelist above. I suppose that we
could at least add comments like:

# Note: Be sure to whitelist your own development project directories:
#whitelist ${HOME}/YOUR_PROJECT_DIR

This is kind of similar to what was added to npm.profile on #3866:

# If you want whitelisting, change the line below to your npm projects directory
# and uncomment the lines below.
[...]
#whitelist ${HOME}/Projects

Which was later changed to the following on #3876:

# If you want whitelisting, change ${HOME}/Projects below to your npm projects directory
# and uncomment the lines below.
[...]
#whitelist ${HOME}/Projects

(And which now lives on nodejs-common.profile since #4255)

Cc: @aidalgol @glitsj16

[rusty-snake]

IMHO we must not ever sandbox build-systems by default as they can require anything.

I don't even sandbox IDEs. The profile are very weak / must be weak (full D-Bus, no whitelisting, minimal blacklisting, ...) the win is very low to nothing but the sandbox regularly breaks things will developing and since nesting isn't supported you can not sandbox the things which really need sandboxing in a tight profile.

[aidalgol]

I am in favour of changing this to make the whitelisting opt-in just as in nodejs-common.profile, and I think nodejs-common.profile should be refactored as part of this set of changes in the same way cargo.profile profile has been.

[rusty-snake]

My idea was that since you already need to type firejail meson compile -C _builddir (for example), using firejail --whitelist=~/my_project_dir meson compile -C _builddir isn't much more complicated. Anyway, will make whitelisting opt-in.

[kmk3]

@rusty-snake on Sep 10:

Anyway, will make whitelisting opt-in.

Thanks. Can you still put a comment above it noting that it's intended to be
changed?

It's not clear to me that it's supposed to be user-customized; I think that the
path could be easily mistaken as something related to a build system.

[kmk3]

@rusty-snake on Sep 9:

I'd say that make is much more general-purpose compared to the rest, so I'd
be very cautious in adding such a profile.

None of these profile are in firecfg.config (for reasons) they are provided
as an starting point for advanced users who want to sandbox make/meson/...
and must be customized (via command-line or .locals) in the most cases.
Because build-systems can require anything, you would need to allow anything
if you want a general profile.

I think it would be nice to eventually have bundler on firecfg.config (I had
wanted to create a profile for it too). I also think that it may be possible
to make a generic enough cmake profile for building system packages.

Since I considered these doable (more than for make at least) and since it
wasn't specified that the profiles in this PR are mostly templates, I assumed
that all of them were really intended to be enabled by default in the future.
If they're all intended to be templates, then I'd rather continue this in a
discussion later.

It can be used with any tool and any programming language, so I don't think
include disable-interpreters.inc makes sense for it.

IMHO adding disable-interpreters by default makes sense, if you need to build
something that requires let's say python, then include allow-python3.inc in
make.local or run firejail --include=/etc/firejail/allow-python3.inc --profile=make make <target>.

Same as above.

[matu3ba]

Many whitelist stuff is not needed and there are no descriptions how this general profile should be used for the important use cases.

[matu3ba]

1 sentence above this block to briefly describe overwrites in profiles.

[matu3ba]

Also here: 1 sentence above this block to briefly describe overwrites in profiles.

[matu3ba]

build systems may be lang-specific or lang-generalizing. Please improve this comment here.

[matu3ba]

Where is noexec used in build system that makes this necessary? A comment line could clarify.

[matu3ba]

Why is access to /run files like cups, dbus needed? We only want to fetch and build stuff.

[matu3ba]

Why is stuff like /usr/share/vulkan x11 etc whitelisted? We only want to fetch and build stuff.

[matu3ba]

Simplified speaking /var is logging for system files, which should not get lost. Build logs are not part of that. Remove that line?

[matu3ba]

Please add the line Description: with Usage information. Especially if this profile should be loaded first or last.
Adapt the whitelist/blacklist accordingly.

Bear in mind that users may want to use the non-system package manager also for projects in $HOME and drop an additional sentence what needs to change for that.

[netblue30]

merged!