Hello, Am Freitag, 15. Februar 2013 schrieb Sascha Peilicke:
On 02/14/2013 10:37 PM, Johannes Weberhofer wrote:
One information I didn't mention in the sentence above: I've never had problems on workstations with enabled apparmor, but I had many problems on servers (samba/ldap/ssh etc.). As soon as you change
AFAIK ldap and ssh don't come with a profile that is enabled by default. For samba, see my previous mail.
default locations or add additional libraries things suddenly don't work as expected until you suddenly realize, it's apparmor which blocks something.
-v (or bugreport) please - which programs/profiles do cause problems?
Exactly. I think we all agree that in theory it's an amazing concept which would indeed increase security. However, in reality, apparmor profiles would have to be included in upstream code-bases or they will quickly run out of sync.
And that would help in which way exactly? Ah, now I remember: > > Ideally, upstream projects would care for AppArmor profiles > > (as much as they would care for SELinux), > Oh, upstream projects really care for SELinux? ;-) At least as much as they do for AppArmor ;-) [> Christian Boltz and Sascha Peilicke in opensuse-factory] (from August 2011) ;-) I'm not against upstreaming profiles - but if "upstreaming" just means "store this file in upstream git", it doesn't really help. If upstream doesn't care, working together with other distributions (and storing the profiles in the AppArmor bzr repo) might be the better idea. For example, Ubuntu comes with an interesting set of profiles.
So far that never happened and we (as a distro) chose to confine only some of the more important daemons. It would be much more important (although not easy) to confine all the javas, flash-players, adobe readers and browsers out there.
This will end up in a policy question. For example, I have a working profile for acroread, but it comes with some restrictions. The most important one is: it allows to read *.pdf files from any location, but _doesn't allow any write access_ except its own config (hint: this breaks File - save a copy and File - save as text, but for my personal use, I don't need them). The advantage of this profile is: even if acroread goes crazy, it can't destroy anything ;-) I could allow write for *.pdf, *.txt and *.ps (for "print to file") - that would make the profile working for most people, but would also make it less secure. A more interesting example is a browser. AFAIK Ubuntu has a profile for firefox (not sure if it's active by default) that allows write access only to ~/Downloads. That's good for security, but might annoy users. This is what I meant with "policy question" - do we prefer security over "support random download locations"? BTW: There are plans to run the "open file" or "save as" dialogs with less restrictions (which would solve lots of problems), but I don't know when this will be available. For details, see https://blueprints.launchpad.net/ubuntu/+spec/security-r-app-helper BTW2: You also mentioned java. Well, asking for a java profile is like asking for a bash or perl profile ;-) and that's not a good idea. Instead, you might want to have profiles for the application using java/bash/perl.
We chose to disable apparmor by default because of the little benefit it has in practice as of today and because of the annoyance it causes once some lower-level system daemon breaks.
Hmm, the breakage seems to be very low if I judge by the number of bugreports ;-)
Of course you could argue that non-working daemons are always the most secure ones but that shouldn't be our goal ;-)
Well, I prefer non-working daemons over exploited daemons ;-) (non-working is easier to detect and easier to fix)
For practical security it is in my opinion much more important to get security updates (especially for the named software) out there ASAP.
You are comparing your car's brakes (AppArmor) with your insurance (security updates) ;-) [1] Security updates are in fact important (thanks to everybody who works on them!), but if you have your applications protected, you are already protected before the security issue is even known or reported ;-) All that said: As usual, security is (unfortunately) not boolean true / false ;-) and it needs several parts to make the system as secure as possible. Regards, Christian Boltz [1] I know car/pc comparisons suck ;-) - but speaking about it, well, see (non-random) sig ;-) -- oh, wieder ein auto/pc-vergleich :-)
Ein Auto und die StVO sind wahrlich primitiv im Vergleich. das mag sein. aber wieviele menschen sterben jährlich durch computerunfälle? [gefunden auf http://www.pro-linux.de/news/2005/8509.html]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org