[apparmor] [opensuse-factory] 12.1 is around the corner, and I must make my concerns known.

[Christian Boltz]

Hello,

[please keep the CC in replies]

on Dienstag, 16. August 2011, Sascha Peilicke wrote:
> > 	1. Have a simple default configuration for Samba, like in Ubuntu
> > 	where it simply works out of the box.
> > 	
> > 		a. Fix AppArmor so it isn't battling with Samba constantly.

The 11.4 profiles were buggy/incomplete, but this was fixed with an 
update in the meantime. Fixed bugs don't count as bugs anymore ;-)

The main problem is that AppArmor needs to be aware of the location of 
your shares. The perfect solution would be that Samba or its initscript 
add the location of all shares (with lrwk permissions) to an AppArmor 
profile sniplet at startup.

See also https://bugzilla.novell.com/show_bug.cgi?id=688040 - most 
interesting comments:

| Comment 2 - Christian Boltz    2011-04-18 22:11:35 CEST  
| Agreed. It would still be worth some bonus points if the samba 
| initscript would auto-generate a profile sniplet with the path of all 
| shares ;-)

| Comment 3 - Lars Mueller    2011-04-20 18:30:08 CEST  
| Free coffee and cake if we see a submit request implementing the 
| suggestion from comment #2 in a way that it works generic with the 
| current sysvinit approach and with systemd too.

Lars didn't write "for the submitter only" - maybe there's someone who 
wants to make him sponsoring coffee and cake for the conference? *eg*

> > 	2. AppArmor desktop notifier. It would be nice for the user to
> > 	know when
> > 	 AppArmor blocks something, and be able to click straight 
> > 	 through to
> > 	the Profile Update wizard. But even somethin as simple as a 
> > 	system announcement would be superior and be picked up by the
> > 	KDE notification system.

There is aa-notify (accidently named /usr/sbin/aa-apparmor_notify in 
11.4). Unfortunately it is underdocumented :-( and since it needs to 
start as root (for read permissions on audit.log), it should probably be 
started by init/systemd.

There's a bit of configuration needed, I can write about the details if 
someone is interested. It works (well, see next paragraph) and gives you 
nice desktop notifications.

Unfortunately a security feature of aa-notify strikes back - it drops 
privileges after startup and then can't access /var/log/audit/ anymore.
I'm just sorting that out with Jamie (one of the AppArmor developers). 
Unless there is a patch, the workaround is   chmod 755 /var/log/audit/ 
(or better use chgrp trusted and chmod 750)

Well, it would have been the first program that I can just use without 
having to report a bug first ;-))

> While the idea behind AppArmor is good, the whole concept dies
> without maintenance. Ideally, upstream projects would care for
> AppArmor profiles (as much as they would care for SELinux), or

Oh, upstream projects really care for SELinux? ;-)

> if not, beloved packagers would spend their precious time maintaing
> AppArmor profiles for each of the many thousands of packages that
> are currently in Factory.

That would be too much ;-)
My policy is that (at least) everything that listens on a network port 
should have a profile - yes, that means (and is) server usage mostly.
I also have some profiles on my workstations for various daemons, and 
even have profiles for some small applications (and even scripts) to 
prevent that I shoot myself in the foot ;-) Needless to say that the 
foot-protecting profiles are very special for my usecase and nothing 
that can or should be packaged.

For protecting desktop applications, see the Firefox example below.

> Reality hits hard in that case, we have around 10 services that have
> really working, up-to-date AppArmor profiles. 

I count 23 profiles in /etc/apparmor.d/ that were installed by rpm on 
11.4. OK, 7 of them are for usr/lib/dovecot/* which you might have 
counted as "1 set of dovecot profiles", but that's still more than 10 
;-)

> The other profiles we ship come from Ubuntu 

Not too surprising given who has the AppArmor developers on the payroll 
nowadays...

> and do not necessarily match or packages. 

I tend to disagree - see (several paragraphs) below ;-)

> The packages with the most security issues have none (like Firefox,

The problem with Firefox (and most "desktop" applications) is: You don't 
know what the users will be doing with them ;-)

The best example is downloading files - if you want to make Firefox 
really secure, you can limit write access (which includes downloads) to 
/home/*/downloads/**. However I'm quite sure that you'll then get lots 
of complaints because of "I can't download files to ~/coolstuff/" ;-)

The alternative that will avoid this complaints is basically this rule:
    /** rw,
but this isn't really more secure than not having a profile at all.
(In fact, someone already posted a modified firefox profile with such a 
rule in bugzilla - but I'm quite sure this will be rejected upstream.

Instead of /**, you could of course use /home/**, /tmp/**, /var/tmp/** 
as possible download locations - but that's already what the filesystem 
permissions make from the /** rule, so it isn't more secure. (A normal 
user doesn't have write permissions at other places, and if someone runs 
Firefox as root, well - I don't even want to think about that...)

> Flash player, 

It might be possible to create a profile for it - AFAIK it doesn't allow 
to save files to disk (except its own config and cookies - but this 
location is hardcoded).

The question is which binary to confine - npviewer.bin might be the best 
candidate. (Does anybody know if npviewer.bin is only used for flash or 
also for other plugins?)

> Adobe Reader).

Adobe reader has two menu entries "Save a copy" and "Save as text", 
which causes the same problems as described for firefox.

> The question is, why do we force this onto (primarily) desktop users
> by default? 

Because even the desktop users are protected by some profiles, for 
example nscd and syslog run on every system and come with active (and 
working!) apparmor profiles by default.

> I'm sure, the seasoned admins using openSUSE will cry
> out loud, how we could actually think about such a move. But really,
> we should either don't enable AppArmor  and/or don't even install
> the packages by default. It just doesn't make any sense.
>
> For most users, the AppArmor experience only involves silently
> failing applications, 

The applications should at least display a "permission denied" error 
message. If not, it's a bug in the application.
(And yes, knowing how to solve that "permission denied" is left to the 
user, similar to wrong file/directory permissions.)

> as we lack desktop integration (as you mentioned). 

No, see aa-notify above.

> And it's one of those daemons (together with auditd)
> that are usually removed first on any fresh installation.

Huh? Really?

> Everyone that would complain about such a move is invited to fix the
> profiles we have or even create  _and maintain_ new ones. 

Sounds like I should blog more instead of silently doing the work ;-)

I already pushed several profile updates and other patches upstream 
(both own changes and patches in the openSUSE package), maintain the 
apparmor syntax highlighing file for vim and in the meantime I also have 
commit access in the AppArmor bzr repo :-)

That said: The best person to maintain a profile is a person who 
actually uses the profiled application. The reason for this is that 
nearly every application that does more than printing "hello world" has 
several config options that might influence which files are accessed.
(I know AppArmor very well, but if you tell me "create a profile for 
$application" it will lack lots of rules if I'm not familiar with 
$application.)

> Otherwise I proposing a grace period for people to step up and get rid 
> of this for 12.1. 

Does the above text count? ;-)

> However, the situation is completely different on SLE, but
> that's not to be discussed here, please.

Sorry to ignore your request, but openSUSE is still the base for SLE 
AFAIK. And with AppArmor disabled by default in openSUSE, you'll have 
more "fun" with the SLE customers when it's enabled by default because 
less people use/test it in openSUSE ;-) 
<BOfH> But why should I care - I don't use SLE *eg* </BOfH>

But the most important point is: it would be a loss for openSUSE if 
AppArmor would be disabled by default.


Regards,

Christian Boltz
-- 
Ich springe so oft aus dem Fenster, daß ich ein schnurloses
Telefon habe.                         [Ratti in suse-linux]