Re: Apparmor suggestion to include more profiles

Christian Boltz <[email protected]> Sun, 29 May 2016 22:28:27 +0200
Newsgroups gmane.linux.suse.security
Message-ID <[email protected]>
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: [email protected]
To contact the owner, e-mail: [email protected]