It has its uses I guess, but it requires opt-in which is a pretty big disadvantage, and then still can't do even a fraction of what SELinux can already do. SELinux isn't that hard to learn, and the security benefits are immense.
2024-01-08 22:34 ubuntu@knope:~$ sudo apparmor_status
apparmor module is loaded.
185 profiles are loaded.
104 profiles are in enforce mode.
(...)
124 processes have profiles defined.
122 processes are in enforce mode.
Transparent limitation is a double-edged sword. From an adversarial perspective, it's good since I'm not advertising what my system can and can't do, and poorly written software may get hung up on timeouts waiting for things to happen. On the other hand, those same benefits against an adversary are negative constraints to usability, as now silent failures can happen on a system, requiring you to watch your AppArmor logs like a hawk when using new software.
Ultimately, less of a concern for servers that likely have limited scope and use cases, but a significant decrease in usability for workstations.
You need to write an AppArmor profile to limit your software. It’s an opt-in system.
The workflow is you put a test system to “complain” mode and use your software as intended, and add the required permissions to the profile by looking at the logs to see what your app is doing. Then you put AppArmor to enforcing mode, add the profile to production system and your application is sandboxed. Iteratively refine as necessary.
Debian desktop comes with AppArmor enabled. Nothing has been broken so far.
And every time you upgrade to the next major release, you start again from square one because the requirements of your software have changed. You get it to work and things seem to be fine. Over time, you start noticing things that are subtly broken, until something just fails completely and doesn't work. The fix turns out to be trivial when you give it another go two days later, but at the time it happened you really didn't have the nerve to deal with it right then.
After two dist upgrades, you realize that this approach isn't workable.
> And every time you upgrade to the next major release, you start again from square one because the requirements of your software have changed.
Nah. That's a huge exaggeration. Most software doesn't change its base behavior like that and certainly not with every new release, and certainly browsers don't.
Because there's already UNIX file permissions which prevent applications to reach places they shouldn't. Confine a daemon to its own user, chroot it, and it's a sitting duck in its own universe.
You add more layers with cgroup/AppArmor/SELinux in Linux, Jails in FreeBSD, unveil on OpenBSD, etc.
You harden as much as necessary. Not "drowned by default".
> Because there's already UNIX file permissions which prevent applications to reach places they shouldn't
Right. Just set up a separate user for Firefox using a single unprivileged command from your user account or a few clicks in your DE, then launch Firefox as that user using another single command or click. Being subordinate to your main user account, the Firefox user's files and directories can easily be managed from your main user and you can move files between subordinate users using just an (unprivileged) chown or chgrp. Accidentally launching applications as your main user is not possible and the system strongly encourages you to create separate, subordinate users for all your applications and is designed from the ground up to make this simple and it works out of the box.
Oh wait, that's not even remotely how any of this works. On a workstation, the "user account" is an almost completely useless concept (as set up and implemented in reality). That's why we have jails/namespaces/etc. Hacks that are piled on top of the useless mess of "user accounts" (all running as the same user, on workstations) trying to solve the same problems, but ultimately failing at providing any kind of comprehensive solution with a coherent vision. Software cannot take anything for granted anymore. Anything that looks like a writable file could be a read-only bind mount. Any mundane syscall could get it SIGKILLed for no reason other than that somebody forgot to add it to the whitelist. But from the user's perspective, there's no reasonable level of security by default.
Considering how we use jails/namespaces and other similar technology, your analogy sounds off. First of all, security is always set up in layers. A different user and chroot doesn't exclude the use of jails, or other kernel level security systems like AppArmor/SELinux. They are layered on top of each other as necessary.
Also, namespaces is not solely a security mechanism. Yes it allows isolation, but it allows resource limitation, too. So you can partition your system to slices and show a particular set of resources to an application (I'm sure you're way more knowledgeable than me in that regard).
On the other hand, security starts with application itself. Then you start to add extra containment barriers if you don't trust the software in question.
What I understand is our realities are completely disparate, and this is not how we hold the mechanisms I talk about. This might be due to the environment each of us live in, or due to our requirements, I don't know.
But, what I know is, the state of security is not as bleak as you portray, and necessity is mother of invention. Except SELinux, AppArmor, and FireJail all of the technologies we talk here are essentially built as virtualization, or virtualization-like technologies. They bring additional security as a secondary effect, and they're good at that.
> Software cannot take anything for granted anymore.
This is why we have stat calls, defensive programming, APIs and exception handling. The first rule of system programming is to never take anything for granted.
I have reached to the end of the time I have for today,
With what purpose? Why do you want two different directories? On second thought, maybe you mean ~/Uploads could be unveiled read-only, though I still don't believe this brings much.
Con: Every time you need to upload a file using your browser, you have to move it to this folder first.