Hello,
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? ;-) At least as much as they do for AppArmor ;-)
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 ;-) Consider it whishful thinking :-)
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. Sounds very reasonable, how about submitting those profiles? Still this somehow supports my argument that it is very useful on servers, less so on end-user machines.
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 ;-) Right, the profiles would be rather complex, you might say. For stuff that changes as frequently as Firefox (plus all the plugins) is quite a task.
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? Depends, you might say, not for you. But we're both vocal minorities, maybe it's more right to just state that noone cares?
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 ;-)
That's the spirit, seems like I reached the correct guy here.
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? ;-)
You don't demand that from our regular users? I mean I only got some insights into writing profiles recently, as I'm forced to do it (you know, policy @work). Still I'm having a hard time confining a daemon running in a Java servlet container (no, not tomcat) with many plugins, auto-update and that polls stuff in the interwebs. The only thing I learned so far that this isn't childsplay :-)
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.
It's merely about opt-in or opt-out and thus, which is more reasonable. Given the current state of our AppArmor integration and the huge community demand, I doubt that. But that's what this thread should be about. -- Mit freundlichen Grüßen, Sascha Peilicke