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] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org