Mailinglist Archive: opensuse-security (12 mails)

< Previous Next >
Re: [opensuse-security] 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: opensuse-security+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-security+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation