Warn when no whitelisting is done in ${HOME}

[kmk3]

Background

The idea came when reading the following thread:

@kmk3 commented on Dec 7:

@rusty-snake commented on Dec 5:

Yes.
If it does not work, use

mkdir ${HOME}/.local/share/applications/wine
read-only ${HOME}/.local/share/applications
read-write ${HOME}/.local/share/applications/wine
ignore read-only ${HOME}/.local/share/applications

Shouldn't that be added to the default wine.profile?

@rusty-snake commented on Dec 7:

It can be used to escape the sandbox, so maybe we should add it as a comment.
On the other hand wine.profile is already open as fuck so I don't care if we
add it enabled. Do what you want.

Rationale

Non-whitelisting profiles do not adequately protect against things like
echo evil >~/.someshellrc, which makes them much less secure than
whitelisting profiles. I'd wager that there may be many firejail users not
fully aware of this. Additionally, it is not made very apparent when a profile
is blacklisting vs whitelisting when running firejail (you'd probably have to
look at least into the main profile being used to be sure).

Proposal

When nothing in ${HOME} is whitelisted, how about printing a warning when
firejail is started? Example:

Warning: no paths were whitelisted in ${HOME}: cannot protect against the creation of malicious startup files (see <url>)

The url could point to a wiki page explaining how to harden profiles through
whitelisting.

Note: There are a few similar messages, but for not blacklisting:

$ firejail --profile=wine true 2>&1 | grep 'not blacklisted'
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted

Thoughts?

Cc: @netblue30

[ghost]

Personally I can fully agree with the described rationale. It took me quite some time to realize the difference between and implications of running apps with blacklisting vs whitelisting profiles. Even more time went into trying to write the latter while keeping some 'reasonable' balance between security and usability.

So yes, I can see the added value of such a CLI warning (explanatory wiki page referal included). Why stop with a CLI warning though? We might as well try to cater to the more GUI-minded Firejail users too (if this can be integrated without adding dependencies). What IMO would also be very worthwhile in this context is some sort of collective refactoring effort: redo as much of our existing profiles as whitelisting ones as (in)humanly possible. Like some kind of sprint(s), usual suspects going over personal collections of local overrides, recurring FWOC events (1), 'anything goes' really.

(1) Firejail Winter Of Code: Strictly non-sponsored, small-scale, cozy, and uplifting virtual code gatherings of the Peoples Of The Firejail Tribes. Rumours have it these soon-to-become-popular events started sometime during the COVID-19 pandemics of the 21st Century at undisclosed locations throughout the InterNets. Counter-balancing the chilling effects of social isolation was typically achieved by consuming several jars of home-made libsoup while dangling head-down from the nearest living tree - a crude reference to the bat populations blamed to have started this global mess.

[kmk3]

@glitsj16 on Dec 9:

Personally I can fully agree with the described rationale. It took me quite
some time to realize the difference between and implications of running apps
with blacklisting vs whitelisting profiles. Even more time went into trying
to write the latter while keeping some 'reasonable' balance between security
and usability.

Indeed, it took me a long time to discover it as well (coincidentally, 1 year
ago this month):

• Email part (2) #3849 (comment)

So yes, I can see the added value of such a CLI warning (explanatory wiki
page referal included).

Before I forget, I think that it would be good to have an explanation on the
man page as well.

Why stop with a CLI warning though? We might as well try to cater to the
more GUI-minded Firejail users too (if this can be integrated without
adding dependencies).

Related:

• fanotify opportunities #4674 (comment)

What IMO would also be very worthwhile in this context is some sort of
collective refactoring effort: redo as much of our existing profiles as
whitelisting ones as (in)humanly possible. Like some kind of sprint(s), usual
suspects going over personal collections of local overrides, recurring FWOC
events (1), 'anything goes' really.

(1) Firejail Winter Of Code: Strictly non-sponsored, small-scale, cozy, and
uplifting virtual code gatherings of the Peoples Of The Firejail Tribes.

I like the sound of that. Before starting a FWOC, I'd personally like to focus
on just getting a CLI warning first, but afterwards it would be great to see
and to help make a wide swath of profiles become whitelisting profiles. It
would probably be helpful to have a ton of testers, so it might be a good idea
to create and to pin an issue for it and also to announce it on the RELNOTES
and on GitHub Releases.

We should probably work on getting a release out before that though (I'll open
a discussion for that), to sync the profiles and thus make it easier to
test/contribute.

Edit: Discussion created: #4770.

[rusty-snake]

FTR using one of the following commands should not trigger the warning:

• read-only ${HOME}
• private
• private ${HOME}/.private-homedir
• private-home .mozilla,Downloads

[kmk3]

@rusty-snake on Dec 10:

FTR using one of the following commands should not trigger the warning:

• read-only ${HOME}
• private
• private ${HOME}/.private-homedir
• private-home .mozilla,Downloads

Good catch. Would it suffice to have a variable to remember whether ${HOME}
was bind-mounted by firejail (by using whitelist or any of the above
commands)?

Then the warning could be something like this instead:

Warning: not bind-mounted: ${HOME}: cannot protect against the creation of malicious startup files (see <url>)