Thought: blacklist all .files and folders by default.

[Fred-Barclay]

We already blacklist most hidden directories and files with disable-common, disable-passwdmgr, and especially disable-programs. Then we noblacklist the files in the appropriate profiles.

This has the weakness of requiring multiple disable.inc files, which can lead to unnecessary duplication, complication, and confusion. It also opens a bit of a security risk in that hidden files that aren't blacklisted are visible to the sandbox. While currently firejail blacklists all the sensitive hidden files, sooner or later there will be one that isn't included in the sandbox that should have been.

Why not just disable them all in a single file? Something like disable-hidden.inc: blacklist ${HOME}/.*.
Then we can just add the necessary noblacklists to the profiles. We do this already since nearly all hidden files are blacklisted already, so most profiles would be ready-to-go as they are right now. A few profiles will have to be modified (esp. if they need .bashrc which is currently visible to the sandbox) but there is plenty of time for debugging before the next firejail release (right, @netblue30 ? 😄)

And on the positive side, a bit of testing in terminal has shown no problems on my side.

Thoughts, mates? My last big change wasn't welcomed by some so I thought I'd get responses before creating a pull request. A rough mental draft is ready to go depending on the feedback.

[chiraag-nataraj]

Sounds like an improvement in security! 😄

[Fred-Barclay]

Thanks. That's what I'm hoping. :)

[Fred-Barclay]

Will probably conflict with #579

[netblue30]

You guys are worse than a six year old :)

@Fred-Barclay: you are right, all the include system is a mess in this moment. What you propose is also somehow releated to #504. Let's leave it open for now, I'll mark it as an enhancement and go for it in the release after the current one.

The thing is I've already started adding private-bin and whitelisting /tmp directory all over the place. Also private-dev and private-etc are in plan. By the time I'm done, everything will be broken. So no messing around with the include files, instead just put in some pull requests with whatever you have in your private profiles. If is working on your setup, it should be fine, and we'll fix it when people start complaining.

[Fred-Barclay]

"You guys are worse than a six year old :)"
I am six and three-quarters! 😉 I'm tellin' my mommy!

Will do. Will the next release be 0.9.41 or 0.9.42? I noticed you seem to use even-numbered point releases.

[netblue30]

0.9.41 is the development tag. It will be released as 0.9.42 once is ready.

[SYN-cook]

@Fred-Barclay An alternative implementation of your idea would be to generally switch to whitelisting, and to whitelist all non-hidden directories in the root of user home (like the XDG defaults ~/Videos, ~/Downloads and so on). From a usability perspective the result would be the same, but the approach has the advantage of effectively handling #1011, which is otherwise fairly trivial to exploit.

Take only Gnome: How many installations out there have one the files ~/.gnomerc, ~/.xsessionrc or ~./xprofile in user home, not even talking about all of them? But all these files are sourced on startup, an attacker just needs to create the one that's missing. Blacklisting would not safe you from that, whitelisting will.

But admittedly rewriting all profiles for whitelisting would be a major effort, and having more restrictive profiles also increases the risk of breaking functionality.

[chiraag-nataraj]

@SYN-cook @Fred-Barclay Do you think we've sufficiently cleaned up the profiles to close this or should we keep it open to motivate us further?

[chiraag-nataraj]

Also, I would suggest maybe going the route I do in my personal profiles: only use whitelists and keep them within the specific profiles (see my repository for examples of what I mean). I use a common.inc which sets up a bunch of rudimentary blacklists and security options (apparmor,caps.drop,seccomp,etc.) which can be overwritten in a program's profile if necessary (ignore <predicate>). The nice thing about this approach is that everything in common.inc is truly common - it should be true by default in every profile (and only disabled if the program doesn't work with it enabled). And since all of the profiles have whitelists for files and directories in ~ (except for maybe one or two, which I'm working on), it's not at all an issue that common.inc doesn't have any blacklists or whitelists of those files.

[chiraag-nataraj]

We've generally been moving in this direction to the point where I think this can be closed. The profiles have been significantly revamped since the issue was first opened, and we're generally keeping this in mind 🙂