Re: Apparmor suggestion to include more profiles

Hallo,

Am 29. Mai 2016, 15:37:07 CEST schrieb Jean-Christophe Baptiste:
> It is a nice thing that openSUSE includes apparmor by default. I
> started to play with it on Leap 42.1.
> 
> However, I feel it is a little short in term of profiles for the
> desktop (all profiles are server oriented).
> 
> In comparison, I retrieved the profiles in Ubuntu :
> 
> 	bzr co lp:apparmor-profiles
> 
> They have some profiles for chromium, firefox, empathy, totem,
> thunderbird and evolution among others. Some big candidates are still
> missing though, like Wireshark.
> 
> I feel such profiles are important, because these applications are
> rather exposed regarding modern threats.
> 
> Do you think it would be legally possible to include them more or less

I don't see a problem with it - the repo contains a LICENSE file which 
declares its content as GPL v2.

> as is in Leap 42.2 and all future releases? Or at least, is there any
> plan to develop more profiles for the desktop?

The problem with those profiles is that they include some restrictions 
the average user won't like ;-)

This is a general problem with profiles for desktop applications. As soon 
as an application comes with File - Open or File - Save as menu items, 
the profile can
a) allow opening and saving files from a specified set of directories
   (for example, the Ubuntu firefox profile AFAIK allows saving files
   only to ~/download/). Unfortunately this will terribly annoy users.
b) allow opening and saving files everywhere, which makes the profile
   pretty useless

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.

There's also an option c) - implement an "external" file dialog that runs 
outside of the AppArmor restrictions. Unfortunately this only exists on 
the wishlist AFAIK, but it would solve most of the problems.


Another problem can be how desktop applications are implemented. 
For example, I'm playing with a profile for Konversation. In theory that 
sounds easy ("allow network communication, and allow to store the IRC 
logs").

Things become funny when you click a link posted on IRC, because 
Konversation first asks (via the KDE libraries etc.) which application 
handles this filetype, and then starts this application. So the profile 
needs to allow starting lots of applications (browser, text editor, 
image viewer etc. ) from Konversation.

This would need to get changed in Konversation itsself - instead of 
finding out itsself which application handles the given filetype and 
starting it, it should let an external program (let's call it 
konversation-link-clicked-helper, or maybe it could just use xdg-open) 
which could then be confined with a more permissive profile to allow 
starting other applications.


After probably disappointing you, I hope you are still interested in the 
profiles from lp:apparmor-profiles ;-)

You are more than welcome to test them and give feedback [1]. If some of 
them do not cause annoyances, I'm more than happy to package them in 
openSUSE.


BTW: An annoying detail is that lp:apparmor-profiles contains several 
dummies that only say "the profile for this application is packaged in 
$packagename", which makes it more difficult to get the actual profile. 
There are plans to get this fixed. I discussed it with some Debian people 
at DebConf15, and if we are lucky, they'll find some time to implement it 
at this year's DebConf next month.

I'm also thinking about creating an apparmor-profiles-paranoid [2] 
package. This package could contain "probably annoying" profiles and 
would only get installed when explicitely requested.


Regards,

Christian Boltz

[1] either here or on the upstream AppArmor mailinglist

[2] the name is inspired by /etc/permissions.secure which also includes
    some annoying restrictions
-- 
"Wirklich praxisnah wären Münzen zu EUR 0,99."
[Wolfgang Schwanke in de.etc.sprache.deutsch]

-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]