https://bugzilla.novell.com/show_bug.cgi?id=724829 https://bugzilla.novell.com/show_bug.cgi?id=724829#c1 Sascha Peilicke changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |suse-beta@cboltz.de --- Comment #1 from Sascha Peilicke 2011-10-21 09:09:14 UTC --- But what's the use-case in enabling it by default? I don't mean servers, but I suspect the vast majority of openSUSE installations to be laptops and workstations. Why would I care that all cmdline-mailers are appropriately confined? As a user, I would be interested in mostly Firefox, Flash and Adobe. It was thought that 'power-users' or admins that want this functionality can enable it easily, IMO but we don't want to bug joe user with that. If this is only 'bout convenience for the sysadmin, I'd say no. We shouldn't enable another daemon just because we can, we already have plenty ;-) Don't you disable half of the default set that doesn't cater your needs, too?. On the other hand, does that tray applet work again? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=724829 https://bugzilla.novell.com/show_bug.cgi?id=724829#c3 Christian Boltz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|suse-beta@cboltz.de | --- Comment #3 from Christian Boltz 2011-10-21 14:09:34 CEST --- My system is far from a default installation, so I don't know exactly which daemons are running by default nowadays. You'll have to compare the list of daemons running by default with the profiles in /etc/apparmor.d/ yourself ;-)

From the things Ludwig mentioned: usr.sbin.avahi-daemon has a profile. usr.sbin.nscd and usr.sbin.ntpd are also things that are started by default IIRC and are protetected by AppArmor.

Of course I use all profiles that are installed by default on my system and everything works - so AppArmor won't "bug joe user with that" ;-) It just sits in the background and adds some additional security. The desktop notification works (it's not a tray applet/icon anymore - it uses /usr/bin/notify-send). You can start it with sudo /usr/sbin/aa-notify -p --display $DISPLAY BTW: the usr.sbin.smbd profile is now even automatically updated based on your shares in smb.conf. Now to the more interesting[tm] things you asked: The problem with firefox and acroread is that they have "save as..." and "open..." in their file menu. This means that I'd have to give them read and write permissions to (more or less) the whole filesystem, which makes having a profile quite pointless. The only thing that would be possible without restricting users would be a set of deny rules where I could blacklist read access to ~/.gnupg and ~/.ssh - but such a blacklist would never be complete. To make the firefox profile really secure, a restriction like "downloads can only be stored in ~/Downloads/" would be needed. That's exactly what the firefox profile in /etc/apparmor/profiles/extras/ does, and it's also the reason why this profile isn't enabled by default. Flash could be easier because it doesn't have "save as..." and "open..." - but I'm not sure at which point between browser and flash a profile could attach. (Does flash run as a standalone process? What's the name of the binary?) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=724829 https://bugzilla.novell.com/show_bug.cgi?id=724829#c5 Christian Boltz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |security-team@suse.de --- Comment #5 from Christian Boltz 2011-11-14 21:58:32 CET --- (In reply to comment #4)

If $FOO would be helpful when $CONDITION is met, we should wait for $CONDITION to happen. Enabling by default means maintaining it,

guess what I'm doing since some months ;-) and I'm also well-known on the upstream mailinglist since years - money quote (from february 2007): ----------

"Quite low" is 1 in 4 billion. Murphy could make me believe you saw it once, but not twice. You could plausibly see it in a stress test rig This _is_ Christian :) he has a knack for finding bugs no one else can.. [> Crispin Cowan and Seth Arnold in apparmor-general]

means updating profiles once application behavior changes. This usually includes bug reports of 'broken' apps first.

I'm using AppArmor on my systems (desktop + some web/mail servers) myself, so there are good chances that I notice it quite fast if a profile needs to be updated.

Maybe the majority of confined services don't change that much, but I would like to see a real assessment of AppArmor before we pretend it adds any value.

Understandable, even if I wonder why nobody asked in the last years ;-) AppArmor is included (and was enabled) since how many years now?

Even if we have some profiles, are we really sure they actually do what they're supposed to do (i.e. catch all security-relevant cases) or is this just a it-feels-safer (tm) solution?

Show me something that makes a system 100% safe, please ;-) If you had written "catch _nearly_ all security-relevant cases", I'd say yes. Upstream is very picky before accepting profile patches (and ask why a change/additional permission is needed if it isn't obvious), therefore I'm sure the profiles don't allow more than they should allow.

Has it been proven that AppArmor itself isn't subject to security issues? Are

The only issue I'm aware of is bug 717209 (fixed in 12.1 by newer upstream kernel), but the impact is very limited - it crashes the current task (which is obviously misbehaving when writing garbage to /proc, so you could even call it a feature ;-)) and triggers a crash dump (if enabled).

there reported cases where it really defeated a security breach?

Counter-question: are there reported cases where your firewall really defeated a security breach? (In theory all applications/daemons are secure, so why would you need a firewall?) The "problem" with such questions is that you will get the answer _after_ something went wrong. Security tools are like a fire insurance - hopefully you'll never need it, but if you don't have one and your house burns down, you'll have a really big problem... Back to the original question: That's something the security team can probably answer better. I'll needinfo them... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=724829 https://bugzilla.novell.com/show_bug.cgi?id=724829#c8 Stephan Kulow changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|NEW |ASSIGNED Component|Patterns |Patterns Product|openSUSE 12.1 |openSUSE 12.2 Target Milestone|--- |Milestone 1 --- Comment #8 from Stephan Kulow 2012-07-10 15:06:32 CEST --- once we have larger live media, we can talk about it. after 12.2 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=724829 https://bugzilla.novell.com/show_bug.cgi?id=724829#c10 --- Comment #10 from Bernhard Wiedemann 2013-09-27 20:00:51 CEST --- This is an autogenerated message for OBS integration: This bug (724829) was mentioned in https://build.opensuse.org/request/show/201180 Factory / patterns-openSUSE -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.