Mailinglist Archive: opensuse-security (12 mails)

< Previous Next >
Re: [opensuse-security] Apparmor suggestion to include more profiles

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

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.


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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-security+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation