Linux security has been criticised[1] for not having security enabled by default, and for allowing users to disable the security measures. This leads to users avoiding setting minimal-rights policies, and leaving the doors open. When security is optional, policy issues in distributions also aren't fixed quickly.
To limit applications rights to a minimum, SELinux, firewalls, and (systemd) sandboxes are all tools that could be used, but aren't in most installs. However, I think we are still lacking user-friendly interfaces (opensnitch is ported from MacOS).
One idea could be to let the desktop environment restrict one more capability a application on every run, inform the user before running it and ask the user after if the software worked correctly. That would gradually lead to a minimum set of software rights.
> One idea could be to let the desktop environment restrict one more capability a application on every run, inform the user before running it and ask the user after if the software worked correctly.
That would only work reliably if one used every single feature of a program, every time one opened it.
I have tried to enable sandboxing for my services, but it is not easy to know what permissions can safely be restricted, without negative effects.
An interactive sandbox UX I like a lot is an app giving me a dialog "Allow", "Deny" with an additional "Remember" button when it does something new (perhaps modulo some time window, as long as it's clear). In certain situations I'd like to be more granular than that, but it would be much better than what we have today. A good way to be more granular is an "Advanced" button that lets you drill down more specifically depending on the resource that is being attempted to access.
Today if I want to send someone a photo I took on <insert newfangled application that can send messages here> I need to grant it permissions to read all of my storage. That's dumb. The OS should delegate access in such a way that I can give the app access to a single file's contents AND be performant/not get in the way for accessing all files if that's what I prefer.
What should NOT be possible is an app asking "hey can I read '/*'?". It should attempt to access specific resources in the namespace, and the OS should be responsible for saying "should this app bug you again about reading your <namespace>?" This gives an only-slightly-more complex UX to users that don't know/care, and gives a lot of flexibility to those that do.
I'd even be fine if it was one-time opt-in like Android "developer mode" which is basically impossible to enable if you're not looking for it.
But how does this interact with Unix command line tools? Any "sandboxing" system that A) either makes comamnd line usage inconvenient or B) completely ignore command line usage is going to create a rift.
Most of these "interactive sandbox UX" approaches basically create a "developer sandbox" where the command line tools can all play together but cannot access external data. And this is where things go downhill. Developers (or even users) DO want from time to time to write a script that accesses their contacts, gets the current GPS position and then does some munching with Perl for whatever obscure reason. Developers DO want from time to time to read whatever stuff Netflix program is storing on their private storage (oh noes!), or what the PDF reading program wants to send to the net.
And then you hit either A or B from above. If A, developer is annoyed and disables your sandboxing, and you are back to stage 1. If B, you are already at stage 1 and developer is annoyed seeing that random Perl scripts can apparently read your contacts list.
I find that any sandboxing approach that fails to actually think of command line usage is just falling in the trap of the "Android/iOS-centric world view". "Apps" may be glorified websites which are trivial to sandbox, but the more generic concept of "programs" is not. This is not only about command line scripts. Command line scripts interact with pipes. Programs, however, interact between themselves in ways we cannot even think of right now.
Which is why year after year you still see completely unsandboxed PCs being used for "productivity" despite tablets and anything else with the Android/iOS model.
The problem with sandboxing is it only works for server processes with very narrow behaviors - it's completely unable to express broad ideas.
My file browser should be able to see my whole system - that's what I want it to do. But I really don't want it to scoop up a list of files on my system, and send it wholesale to a network address I didn't type in specifically, after some specific actions.
AFAIK no security mechanism anyone currently proposes properly captures this sort of intent: there isn't a firewall which defines what can be done with the actual bytes of data an application has picked up in those terms - when they're in memory.
Of course this is a huge challenge: proving that my file browser doesn't have a way to, without gating through a user system, transform my file list into any code paths which can send it via network traffic.
> Today if I want to send someone a photo I took on <insert newfangled application that can send messages here> I need to grant it permissions to read all of my storage
Yes
> That's dumb
In that context, yes.
But:
> An interactive sandbox UX I like a lot is an app giving me a dialog "Allow", "Deny" with an additional "Remember" button
Everytime you'd want to access any file (eg. upload a saved photo to instagram), you'd get a permissions prompt, and everybody clicks "allow all" after the second time.
The workaround is to have the app ask the trusted OS module to open the file selector, and the user then selects the file, and the app only gets access to that one file. This works for instagram for example.
...but! This doesnt work for file browser apps, file synchronisation apps, backup apps, etc. This also doesn't work with instagram, which offers to upload the last photo taken when you select photo (instead of camera), because it doesn't have permission to load it, and that means an additional step just to select the photo. If you want instagram photos to be saved to your device storage, instagram either needs permission to write to some folder, or it has to ask the os (and then user) where to save the photo every time.
If you want security, features and user friendliness, you're basicaly fscked
As an example, Flatpak has "portals" for e.g. file access, which mirror how this works on mobile OSes. The app asks the environment to let the user pick a file, then the file gets mapped into its sandbox.
This suggestion shows little understanding of the difference between Linux the kernel and Linux the OS distribution. It is the role of distributions to implement defaults for security. The idea, ask the user, is naive - most Linux software never interacts with a GUI or console user.
I think that is why you should choose your Linux flavour well? Perhaps the argument is that developers (especially ones that deploy to production) should better choose theirs?
I think being able to change anything and everything is a philosophy for programming in general and that it shouldn't be played off against security. I do think that for mission critical deployments you should have custom security (I think the Eurofighter Typhoon uses a microkernel not unlike MINIX) but I am in two minds about whether systems are insecure because of the default software or because of the lack of interest in security by people who are trying to pay their bills.
Opensnitch is not a port from macOS. It is a GUI layer-7 firewall, like good ol' ZoneAlarm or -indeed- Little Snitch. Code-wise, it has nothing to do with Little Snitch. The development is also stalled (there's an active fork though).
Does OpenBSD's pledge require or have user-friendly GUIs? Are there good GUIs for PF?
I think the reason security on Linux is so underused is because most of the software desktop Linux users run is very well behaved (compared to popular software on most consumer OSes.) I'd be willing to bet the majority of users aren't running anything closed source outside of a VM (and most that are probably only have one or two apps.) Closed desktop Linux apps are pretty unpleasant even when they run well.
So there's little need for tools like SELinux and add to that how unpleasant they are to use and that's why no one uses them.
To limit applications rights to a minimum, SELinux, firewalls, and (systemd) sandboxes are all tools that could be used, but aren't in most installs. However, I think we are still lacking user-friendly interfaces (opensnitch is ported from MacOS).
One idea could be to let the desktop environment restrict one more capability a application on every run, inform the user before running it and ask the user after if the software worked correctly. That would gradually lead to a minimum set of software rights.
[1] https://www.youtube.com/watch?v=OXS8ljif9b8