[Proposal] Convert all profiles to a whitelist model

[chiraag-nataraj]

I really think we should move towards a whitelist model for profiles, at least by default. In most cases, it's very clear which directories need to be whitelisted, and in cases where it's not, we can stick to the current blacklist-based model. What do people think? I'm willing to sit down and convert many of them (I already have a bunch in my repo, which should help), but I don't want to do it if we decide that it's not a good idea to do this at this time.

[SkewedZeppelin]

We discussed this a while ago, nearly all whitelist capable profiles are already. The only way we could make them all whitelist-only is if we add many more controls for users to specify their paths for different things.

Overall as it is now is probably close to perfect. Furthering with path restrictions in $HOME will increase the difficulty and cause users to stop using it.

[chiraag-nataraj]

😞 Fair enough.

[chiraag-nataraj]

I guess I don't see restricting browsers and most other programs to ${DOWNLOADS} and their own folders (and possibly ${DOCUMENTS} or something else depending on the program) as being that hard to deal with. Maybe it's just a personal thing, but I actually find it more intuitive that programs can't access whatever directories they want and are restricted to a specific set of well-known directories.

[chiraag-nataraj]

Actually, I will re-open. What additional controls do you think we need?

[SkewedZeppelin]

Well I really like the whole disable-xdg.inc thing, but it is limited to Documents, Pictures, Music, and Videos.
We have Downloads and Desktop which I consider to be catch-all directories.

We could further lock down many of the IDE profiles if we had a Development variable. But then how do you handle people with their code or in other directories? Datasets on another drive?

I don't know what controls we would need. There are so many ways. Like whitelist options that only enable if a config option is enabled.

Or our own xdg like config to allow users to define categories to their folders. Like a setup wizard that would let a user mark what all of their directories are and then each profile would define what categories they need access to.

But how would you make a whitelist only image viewer even with categories?
What about when someone has their backup drive connected? etc.

.

I still want a whitelist-noblacklisted option, it would make it easier to convert blacklist to whitelist profiles and to maintain them. See SkewedZeppelin@0f1e887 and #1569

[chiraag-nataraj]

We could further lock down many of the IDE profiles if we had a Development variable. But then how do you handle people with their code or in other directories? Datasets on another drive?

That can be handled by local modifications for people who need it. They can whitelist additional directories in .local files. I mean, the fact that not everyone uses these directories doesn't negate the fact that most people do use these directories, and using the canonical directories as a reasonable whitelist makes sense. Given that you can always extend that with e.g. ignore disable-mnt and whitelist <additional directory>, I don't see what the problem is with having a reasonably restricted whitelist by default.

[chiraag-nataraj]

IDEs specifically are a bit tricky in that their canonical directories aren't necessarily fixed (e.g. Eclipse lets you set the workspace location). But again, we can set sensible defaults and .local modifications will take care of the rest.

[chiraag-nataraj]

Already, many of our profiles will require some local modifications. For example, some people had their /tmp mounted in /mnt or something. That doesn't mean we shouldn't enable disable-mnt by default, right?

[SkewedZeppelin]

I think we should try to minimize the need of .local profiles as much as possible, unless the benefit dramatically outweighs the hassle of it (like disable-mnt does).
(As it stands now a user can just apt install then firecfg, which is dead simple and should be maintained)

Unless we create an easy way to allow users to define what directories are what, I don't think we'll be able to much further restrict directories in $HOME.

[SkewedZeppelin]

In the short term, if we want to convert some blacklist profiles to whitelist-only without breakage:

• Add a new profile option called if-strictmode
  • This would prefix all restrictive options that are common but might break more complicated setups
  • So: if-strictmode whitelist ${DOCUMENTS} could be added to LibreOffice
• Add a new option strictmode to firejail.config
  • This would enable all options masked by the if-strictmode
• Add a prompt when firecfg is run that asks if they want to enable strictmode

[chiraag-nataraj]

I guess I'll continue doing those on my own then 😂 I understand where you're coming from - I guess I just completely disagree with the premise. I think it's reasonable to expect that most people will use the canonical folders (i.e. the defaults) for the programs they use, and I don't see any harm in restricting the program to those folders by default.

[chiraag-nataraj]

Huh, that would be interesting. We should think about implementing that :)

[SkewedZeppelin]

The issue is that a lot of programs don't have defaults.
GIMP stores in ~/Documents by default, but a user might want it to be in ~/Pictures.
And then a freelancer/artist might want to have a ~/Work folder.
Or when they archive stuff to an external drive.

I want strict profiles, but I also want to maintain the ease of use and not cause users to turn away/uninstall when they realize they have to edit a bunch of config files.

[Vincent43]

IMO it would be great to have option for blacklisting all dotfiles in user $HOME (unless there is noblacklist or whitelist option used for specific files). I don't think users are creating custom dotfiles (if they do, they are probably more advanced and can handle it in .local) and with recent XDG black/whitelisting it will be easy to create quite strict sandbox, example:

whitelist ~/.config/app
whitelist ~/local/share/app
include whitelist-common.inc
blacklist .dotfiles
blacklist $XDG_VIDEOS

[curiosity-seeker]

@chiraag-nataraj : I think it's a great idea. However, I think before implementing this it would be necessary to improve file globbing. For example, a rule like

whitelist ${HOME}/*.pdf

does not work. This makes creating whitelisted profiles for applications like Okular and Gwenview difficult or, at least, not very efficient.

Sidenote: It's really great that you've attended to many "forgotten" issues here in the past days. Many thanks for your efforts!!!

[chiraag-nataraj]

@curiosity-seeker: Yeah, we definitely need to implement #216.

And thanks hehe :)

[chiraag-nataraj]

Although...at that point, would it be better to use apparmor to allow access e.g. only to PDF files? I don't know...

[Vincent43]

AppArmor rules affect all profiles

[chiraag-nataraj]

Oh right, nvm.