Hello, Am 29. Mai 2016, 20:05:42 CEST schrieb Jean-Christophe Baptiste:
Thank you for your reply!
The problem with annoying users is they will tend to just disable AppArmor, and, worse, will recommend this to other users whenever they hit an AppArmor restriction. That's something I'd really like to avoid. Yes, it makes perfect sense. We all want to avoid a SELinux situation :-) I personnally did use it for a while, but most people I know are disabling it.
I intentionally avoided to mention SELinux, but the situation you describe is also what I heard ;-)
After probably disappointing you, I hope you are still interested in the profiles from lp:apparmor-profiles ;-)
No problem, I am happy to have your point of view which is very instructive! :-) I will keep playing with them but with a different approach.
I am convinced that, while it is technically possible, we can never, in real life, implement this "white list" approach for any complex application. By white list, I mean trying to have a complete view of all features and actions that a given app is going to do on the system, and, based on that, trying to make a profile with allow/deny filters. We are doomed to spend enormous amount of times, forget some stuff or being too restrictive.
It's not impossible, "just" hard ;-) - I've even seen a working profile for LibreOffice which restricted it to the file types it can handle. Of course, daemons are much easier to confine than anything with a File - Open menu item (or the CLI equivalent of it).
This approach aims to prevent an exploit to escalate its privileges. Under this constraints, an attacker cannot go beyond the normal behavior of the compromised application.
But I want to investigate another approach, because I think it does not make sense on the desktop. It does make sense on a server, because we want to avoid a privilege escalation on the OS, which could impact other services and help the attacker to maintain his access for a long time.
However, it is a different story on the desktop.
For instance, let's say my browser was compromised. As a user, do I really care if then the OS gets also compromised? Would it be even a priority for the attacker? Maybe, but in most cases, both will more care about the data, for instance what's in /home.
I'd say you should care for both. Of course an user will first care about his/her data - but with a compromised system, I'd argue that everything (including the data) can no longer be trusted. That said - the system is usually protected by the file permissions already (assuming/hoping nobody starts firefox as root), so the focus can indeed be on protecting user data. This brings us back to the File - Open and File - Save as problem ;-)
So why not having a simpler approach of blacklisting confidential folders? I am thinking about that .ssh or EncFS folder that contains secrets I really care about. Such a setting would be easy to configure and, I guess, very understood by the average user.
You might want to look at /etc/apparmor.d/abstractions/private-files and .../private-files-strict ;-) You might also want to look at the sanitized_helper profile defined in /etc/apparmor.d/abstractions/ubuntu-helpers (typically included in other profiles as child profile, but using it as "real" profile should be easy). Please read the comment in the file before using it. This is obviously not the best solution, but still better than nothing.
You can have such a setting in a file included in all profile, and you can make dummy packages for almost every application that just include this base file. I want to try such settings, which, along with notifications, would make a nice HIDS.
What do you think about it?
It's definitively worth a try ;-) and better than nothing. Regards, Christian Boltz --
Programmieren in C++ hält die grauen Zellen am Leben. Es schaerft alle fuenf Sinne: den Schwachsinn, den Bloedsinn, den Wahnsinn, den Unsinn und den Stumpfsinn. [Felix von Leitner und Holger Veit in doc]
-- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org