[opensuse-factory] 12.1 beta, apparmor not installed automatically

newer
[opensuse-factory] Time to rehash...

Dieter Werner

5 Oct 2011 5 Oct '11

16:33

Hi, I installed 12.1 beta x86_64 with KDE in kvm as a fresh install I basically used the default settings. I noticed the following: - no apparmor package was installed is it not longer used in 12.1? - the "kickoff" application starter misses the "go back" arrow on the left side of menus containing subentries. e.g. (I use german language setting) "Anwendungen"->"Internet"->"Webbrowser" In 11.4 when you navigate to "Internet" or "Webbrowser" you have a bar along the left edge of the menu with a triangle pointing to the left which allows to navigate back to the previous menu level. In 12.1 beta this bar is missing. To navigate back I so far found only the links on top of the menu under the search bar. BTW: in my "Internet" menu the "Nachrichtenbetrachter" (akregator) entry is duplicated. In general: 12.1 beta looks very good and feels fast even in the VM. Kind regards, Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

C

5 Oct 5 Oct

17:51

On Wed, Oct 5, 2011 at 18:33, Dieter Werner wrote:

...

- the "kickoff" application starter misses the "go back" arrow on the left side of menus containing subentries.

It's not "missing"... it has been changed in KDE4.7 and higher. The "go back" arrow has been removed, and now you have a breadcrumb on the upper right. C. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stephan Kulow

6 Oct 6 Oct

08:42

Am Mittwoch, 5. Oktober 2011 schrieb Dieter Werner:

...

Hi,

I installed 12.1 beta x86_64 with KDE in kvm as a fresh install I basically used the default settings. I noticed the following:

- no apparmor package was installed is it not longer used in 12.1? That's true. It's still on DVD though.

Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Tim Edwards

09:21

On Thursday, October 06, 2011 10:42 AM, "Stephan Kulow" wrote:

...

Am Mittwoch, 5. Oktober 2011 schrieb Dieter Werner:

...
Hi,

I installed 12.1 beta x86_64 with KDE in kvm as a fresh install I basically used the default settings. I noticed the following:

- no apparmor package was installed is it not longer used in 12.1? That's true. It's still on DVD though.

What replaces it in 12.1? Or is it just not needed on the kind of systems (mostly desktop, laptop) that Opensuse is intended to be used on? Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stephan Kulow

09:33

Am Donnerstag, 6. Oktober 2011 schrieb Tim Edwards:

...

On Thursday, October 06, 2011 10:42 AM, "Stephan Kulow"

wrote:

...
Am Mittwoch, 5. Oktober 2011 schrieb Dieter Werner:

...
Hi,

I installed 12.1 beta x86_64 with KDE in kvm as a fresh install I basically used the default settings. I noticed the following:

- no apparmor package was installed is it not longer used in 12.1?

That's true. It's still on DVD though.

What replaces it in 12.1? Or is it just not needed on the kind of systems (mostly desktop, laptop) that Opensuse is intended to be used on? We never had apparmor in real use by default. If you wanted to secure your system, you had to do manual work. And now we added one more step for those: install apparmor pattern. For everyone else, the system is faster.

Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Ludwig Nussel

09:58

Stephan Kulow wrote:

...

Am Donnerstag, 6. Oktober 2011 schrieb Tim Edwards:

...
On Thursday, October 06, 2011 10:42 AM, "Stephan Kulow" wrote:

...
Am Mittwoch, 5. Oktober 2011 schrieb Dieter Werner:

...
I installed 12.1 beta x86_64 with KDE in kvm as a fresh install I basically used the default settings. I noticed the following:

- no apparmor package was installed is it not longer used in 12.1?

That's true. It's still on DVD though.

What replaces it in 12.1? Or is it just not needed on the kind of systems (mostly desktop, laptop) that Opensuse is intended to be used on? We never had apparmor in real use by default. If you wanted to secure your system, you had to do manual work. And now we added one more step for those: install apparmor pattern. For everyone else, the system is faster.

No doubt about that. I was baffled when I noticed the installed profiles are mostly useless in a default install and the init script dog slow (see also bnc#689458). Who is 'we' though? I would have expected that the security team is asked before changing security features of the distribution. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stephan Kulow

10:19

Am Donnerstag, 6. Oktober 2011 schrieb Ludwig Nussel:

...

No doubt about that. I was baffled when I noticed the installed profiles are mostly useless in a default install and the init script dog slow (see also bnc#689458). Who is 'we' though? I would have expected that the security team is asked before changing security features of the distribution.

I had the impression you and Marcus at least are part of this list. http://lists.suse.de/opensuse-factory/2011-08/msg00345.html triggered no response and as such Sascha changed the patterns. And at that point, Jeff was basically saying that he does not maintain appamor and the security team didn't care that it was bitrotting either. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Ludwig Nussel

10:44

Stephan Kulow wrote:

...

Am Donnerstag, 6. Oktober 2011 schrieb Ludwig Nussel:

...
No doubt about that. I was baffled when I noticed the installed profiles are mostly useless in a default install and the init script dog slow (see also bnc#689458). Who is 'we' though? I would have expected that the security team is asked before changing security features of the distribution.

I had the impression you and Marcus at least are part of this list. http://lists.suse.de/opensuse-factory/2011-08/msg00345.html triggered no response and as such Sascha changed the patterns.

I don't read each and every mail esp if the subject seems uninteresting. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Sascha Peilicke

10:51

On Thursday 06 October 2011 12:44:18 Ludwig Nussel wrote:

...

Stephan Kulow wrote:

...
Am Donnerstag, 6. Oktober 2011 schrieb Ludwig Nussel:

...
No doubt about that. I was baffled when I noticed the installed profiles are mostly useless in a default install and the init script dog slow (see also bnc#689458). Who is 'we' though? I would have expected that the security team is asked before changing security features of the distribution.

I had the impression you and Marcus at least are part of this list. http://lists.suse.de/opensuse-factory/2011-08/msg00345.html triggered no response and as such Sascha changed the patterns.

I don't read each and every mail esp if the subject seems uninteresting. Hehe, unrelated to that, cboltz started fixing the profiles we ship, so apparmor even got better after we removed it from the default patterns :-) -- Viele Grüße, Sascha

Lars Müller

15:22

On Thu, Oct 06, 2011 at 12:51:48PM +0200, Sascha Peilicke wrote:

...

On Thursday 06 October 2011 12:44:18 Ludwig Nussel wrote:

...
Stephan Kulow wrote:

...
Am Donnerstag, 6. Oktober 2011 schrieb Ludwig Nussel:

...
No doubt about that. I was baffled when I noticed the installed profiles are mostly useless in a default install and the init script dog slow (see also bnc#689458). Who is 'we' though? I would have expected that the security team is asked before changing security features of the distribution.

I had the impression you and Marcus at least are part of this list. http://lists.suse.de/opensuse-factory/2011-08/msg00345.html triggered no response and as such Sascha changed the patterns.

I don't read each and every mail esp if the subject seems uninteresting. Hehe, unrelated to that, cboltz started fixing the profiles we ship, so apparmor even got better after we removed it from the default patterns :-)

And therefore we turn it on by default again? Oh, yes, the initial startup time of the system is more important than security. Can't we populate the apparmor cache as part of the installation/ upgrade/ maintenance of the system? AA caused issues to Samba in the past. Nevertheless I like to have it enabled by default again. With profiles wher we're not sure if they work correctly we might run it in complain mode. This reminds me to the open issue we had discussed in the past with regard to Samba, YaST, AA, and newly added shares. \: Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Christian Boltz

7 Oct 7 Oct

01:07

Hello, am Donnerstag, 6. Oktober 2011 schrieb Lars Müller:

...

On Thu, Oct 06, 2011 at 12:51:48PM +0200, Sascha Peilicke wrote:

...

...
Hehe, unrelated to that, cboltz started fixing the profiles we ship, so apparmor even got better after we removed it from the default patterns :-)

That might sound like a fun fact, but is totally unrelated ;-) For the records: I started to work on the apparmor package (upstreaming patches etc.) before it was removed from the default pattern.

...

And therefore we turn it on by default again?

s/?/!/, and I couldn't agree more!

...

Oh, yes, the initial startup time of the system is more important than security.

Hey, I didn't mention that rule in my talk about the golden rules of bad programming, but it would have fit very good there ;-)

...

Can't we populate the apparmor cache as part of the installation/ upgrade/ maintenance of the system?

I'll enable caching, see my reply to Coolo's mail for details. However I don't want to package the cached files because that might cause funny side effects on updates (profile changed locally, but packaged cache looks newer and such stuff).

...

AA caused issues to Samba in the past. Nevertheless I like to have it enabled by default again. With profiles wher we're not sure if they work correctly we might run it in complain mode.

That might be an option, but I'm not really happy with shipping profiles in complain mode - users probably expect that all profiles are in enforce mode. IMHO the better way is to ship them in the "extras" profile directory /etc/apparmor/profiles/extras/ where aa-genprof will pick them up as template. That said: There's a better solution for the samba profile, see below.

...

This reminds me to the open issue we had discussed in the past with regard to Samba, YaST, AA, and newly added shares. \:

Indeed, I'm aware of https://bugzilla.novell.com/show_bug.cgi?id=688040 The quick and easy solution would be a little script that extracts the paths of all shares from smb.conf and writes an apparmor profile sniplet. This script should run when starting and reloading samba. The downside is that it won't be aware of everything because - you can reload samba using SWAT instead of the initscript or systemd - it's possible to add "dynamic" shares that don't show up in smb.conf (for example using the "share directory" feature in KDE) Covering all this makes things really difficult, therefore I'd say we should at least do the easy part (based on smb.conf) for 12.1. That's much better than the current state and will probably cover most usecases. If someone can provide a script that prints the path of all shares in smb.conf (there are some hints about python and perl modules to parse smb.conf in the bugreport) in the format given below I'll then integrate it in the initscript and systemd service file. This is how the apparmor profile sniplet should look like: # autogenerated at samba startup - do not edit! /path/to/share/ rk, /path/to/share/** lrwk, /another/share/ rk, /another/share/** lrwk, Regards, Christian Boltz -- Fernsehen und IP sind halt doch zwei verschiedene Dinge, auch wenn beides oft mit Strom funktioniert. [Peer Heinlein in postfixbuch-users] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Tim Edwards

09:14

On Friday, October 07, 2011 3:07 AM, "Christian Boltz" wrote:

...

...
AA caused issues to Samba in the past. Nevertheless I like to have it enabled by default again. With profiles wher we're not sure if they work correctly we might run it in complain mode.

That might be an option, but I'm not really happy with shipping profiles in complain mode - users probably expect that all profiles are in enforce mode.

IMHO the better way is to ship them in the "extras" profile directory /etc/apparmor/profiles/extras/ where aa-genprof will pick them up as template.

That said: There's a better solution for the samba profile, see below.

...
This reminds me to the open issue we had discussed in the past with regard to Samba, YaST, AA, and newly added shares. \:

Indeed, I'm aware of https://bugzilla.novell.com/show_bug.cgi?id=688040

The quick and easy solution would be a little script that extracts the paths of all shares from smb.conf and writes an apparmor profile sniplet. This script should run when starting and reloading samba.

The downside is that it won't be aware of everything because - you can reload samba using SWAT instead of the initscript or systemd - it's possible to add "dynamic" shares that don't show up in smb.conf (for example using the "share directory" feature in KDE)

Covering all this makes things really difficult, therefore I'd say we should at least do the easy part (based on smb.conf) for 12.1. That's much better than the current state and will probably cover most usecases.

If someone can provide a script that prints the path of all shares in smb.conf (there are some hints about python and perl modules to parse smb.conf in the bugreport) in the format given below I'll then integrate it in the initscript and systemd service file.

This is how the apparmor profile sniplet should look like:

# autogenerated at samba startup - do not edit! /path/to/share/ rk, /path/to/share/** lrwk, /another/share/ rk, /another/share/** lrwk,

I might have read your post wrong but are you saying that Apparmor willl, by default, break the file/folder sharing feature built into KDE? This IMHO is completely wrong, you don't enhance security by simply breaking features, especially the most user-facing ones that are there in the GUI. IIRC Redhat was very careful not to deploy profiles for services in SELinux until they were well tested and work. Putting half-working profiles in Apparmor is not the way to go, otherwise soon 'Disable Apparmor' will become part of the standard troubleshooting advice on the Opensuse forum. Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Christian Boltz

11:28

Hello, Am Freitag, 7. Oktober 2011 schrieb Tim Edwards:

...

I might have read your post wrong but are you saying that Apparmor willl, by default, break the file/folder sharing feature built into KDE?

In theory it could. Practise is (as usual) different - the default profile allows sharing the home directories. This means: if you share something in your home directory, everything will work. The only thing that will not work with the default profile is sharing a directory outside your home directory (for example /tmp), but I'd say that's an acceptable restriction because most people won't share /tmp ;-) Let me ask the other way round: did you ever hit an apparmor restriction when sharing a folder in KDE?

...

This IMHO is completely wrong, you don't enhance security by simply breaking features, especially the most user-facing ones that are there in the GUI.

I couldn't agree more - and that's the reason why we don't have a profile for firefox by default. Basically all programs with a "save as..." menu item are impossible to profile because you never know where a user wants to store his files. Well, you could allow write access everywhere, but that doesn't really bring a security improvement. The secure option for firefox would be to allow write access only to ~/downloads (and nowhere else). However that's something that isn't acceptable for a default profile.

...

IIRC Redhat was very careful not to deploy profiles for services in SELinux until they were well tested and work.

SELinux is a slightly ;-) different beast and much more complex AFAIK (did you ever compare an apparmor profile to a SELinux profile?). Nevertheless I'm quite sure they had some incomplete profiles because behaviour of many programs depends heavily on config options, and you never get everything in the first attemp.

...

Putting half-working profiles in Apparmor is not the way to go, otherwise soon 'Disable Apparmor' will become part of the standard troubleshooting advice on the Opensuse forum.

It isn't yet? That's good news and shows that the default profiles use sane rules ;-) Besides that, the default advice in this case should be "check /var/log/audit/audit.log and open a bugreport if needed". Gruß Christian Boltz --

...

Can I get some more info from the machine? 'dmesg', 'cat /proc/bus/input/devices', etc ... Sorry, there's no command calles "etc" on my machine... ;-) [Rasmus Plewe on https://bugzilla.novell.com/show_bug.cgi?id=176022] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Tim Edwards

12:13

On Friday, October 07, 2011 1:28 PM, "Christian Boltz" wrote:

...

Hello,

Am Freitag, 7. Oktober 2011 schrieb Tim Edwards:

...
I might have read your post wrong but are you saying that Apparmor willl, by default, break the file/folder sharing feature built into KDE?

In theory it could. Practise is (as usual) different - the default profile allows sharing the home directories. This means: if you share something in your home directory, everything will work.

The only thing that will not work with the default profile is sharing a directory outside your home directory (for example /tmp), but I'd say that's an acceptable restriction because most people won't share /tmp ;-)

If that's how it works then fair enough, that sounds like it doesn't actually break the feature.

...

Let me ask the other way round: did you ever hit an apparmor restriction when sharing a folder in KDE?

I'm not sure why but I could never get it working on 11.4, I ended using fish:// in dolphin instead since I only need to transfer files to my netbook occasionally. Apparmor definitely did break my simple local-users only Dovecot setup though, and the bug I raised was closed as fixed even though it wasn't for me. <snip>

...

...
IIRC Redhat was very careful not to deploy profiles for services in SELinux until they were well tested and work.

SELinux is a slightly ;-) different beast and much more complex AFAIK (did you ever compare an apparmor profile to a SELinux profile?).

Nevertheless I'm quite sure they had some incomplete profiles because behaviour of many programs depends heavily on config options, and you never get everything in the first attemp.

Maybe, but after my experience with dovecot I got the impression that the Apparmor profiles weren't widely tested and were bitrotting. Maybe that's changed recently though.

...

...
Putting half-working profiles in Apparmor is not the way to go, otherwise soon 'Disable Apparmor' will become part of the standard troubleshooting advice on the Opensuse forum.

It isn't yet? That's good news and shows that the default profiles use sane rules ;-)

Besides that, the default advice in this case should be "check /var/log/audit/audit.log and open a bugreport if needed".

It's not exactly user friendly. Can't it use the desktop notification thing (whatever it's called) to pop-up a notification when it blocks something? Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dieter Werner

12:31

Am Freitag, 7. Oktober 2011, 14:13:46 schrieb Tim Edwards:

...

On Friday, October 07, 2011 1:28 PM, "Christian Boltz"

snip...

...

...
...
Putting half-working profiles in Apparmor is not the way to go, otherwise soon 'Disable Apparmor' will become part of the standard troubleshooting advice on the Opensuse forum.

It isn't yet? That's good news and shows that the default profiles use sane rules ;-)

Besides that, the default advice in this case should be "check /var/log/audit/audit.log and open a bugreport if needed".

It's not exactly user friendly. Can't it use the desktop notification thing (whatever it's called) to pop-up a notification when it blocks something?

whether pop ups are user friendly depends on the user :-) maybe there could be instead/confgurable a mail to root/the system-mail- receiver. Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Christian Boltz

9 Oct 9 Oct

23:54

New subject: [opensuse-factory] apparmor and dovecot (was: Re: 12.1 beta, apparmor not installed automatically)

Hello, FYI: apparmor packages with caching enabled are just building in security:apparmor:factory and also submitted to Factory (SR 87208). Am Freitag, 7. Oktober 2011 schrieb Tim Edwards:

...

On Friday, October 07, 2011 1:28 PM, "Christian Boltz" wrote:

...

...
Let me ask the other way round: did you ever hit an apparmor restriction when sharing a folder in KDE?

I'm not sure why but I could never get it working on 11.4, I ended using fish:// in dolphin instead since I only need to transfer files to my netbook occasionally.

Maybe the failure was/is on the samba side - if I understood Lars' mail correct, it's broken at least in samba 3.6. But fish:// is the better choice anyway ;-)

...

Apparmor definitely did break my simple local-users only Dovecot setup though, and the bug I raised was closed as fixed even though it wasn't for me.

I guess you are talking about https://bugzilla.novell.com/show_bug.cgi?id=681267 I don't have the 11.4 profiles here at the moment (I'm using factory), so I can't check it right now. But I'll help you to solve the problems you see ;-) First check if you are using the profiles from the apparmor-profiles package or modified (maybe outdated) profiles: rpm -V apparmor-profiles If you see anything related to dovecot in the output, please mv /etc/apparmor.d/*dovecot* /some/where/ zypper in -f apparmor-profiles rcapparmor reload If you still see problems, please - switch the dovecot profiles to complain mode: aa-complain /etc/init.d/*dovecot* - run dovecot for some time - open a new bugreport and attach your audit.log. You can also test with the latest upstream profiles. The easiest way to get them is installing the apparmor-profiles package from security:apparmor:factory. I never tested if updating only the profiles works dependency-wise - if rpm complains, it should be safe to use --nodeps in this case. (OTOH, updating to all packages from security:factory:apparmor will give you some more bugfixes compared to the version on 11.4.) Afterwards make sure that you really have the latest profiles: rpm -V apparmor-profiles should not print anything related to dovecot. If you want to update the profiles yourself, run aa-logprof Nevertheless please open a bugreport with audit.log attached.

...

Maybe, but after my experience with dovecot I got the impression that the Apparmor profiles weren't widely tested and were bitrotting. Maybe that's changed recently though.

The problem is that many programs behave different depending on their configuration and usage, which makes it hard to create a perfect profile. To give you an example: traceroute (which is a quite simple program when compared to dovecot) had a good profile. Well, except if you used the -I flag... (see bug 685674) But this example also shows that the profiles are not bitrotting ;-)

...

...
Besides that, the default advice in this case should be "check /var/log/audit/audit.log and open a bugreport if needed".

It's not exactly user friendly. Can't it use the desktop notification thing (whatever it's called) to pop-up a notification when it blocks something?

aa-notify isn't started by default. If you want to use it, run sudo DISPLAY=$DISPLAY /usr/sbin/aa-notify -p Unfortunately aa-notify is slightly broken in 11.4. If you want to use it, run chmod 750 /var/log/audit or install the packages from security:apparmor:factory. Factory already contains the working version. BTW: the need for handing over $DISPLAY is caused by the very secure sudo config in openSUSE - it resets most environment variables. Maybe I get a more user-friendly way implemented upstream, but I'm afraid you'll always have to hand over $DISPLAY (or $DBUS_SESSION_BUS_ADDRESS) to aa-notify. Yes, I'm aware that this isn't a perfect solution, but it's the best I can offer for 12.1. Regards, Christian Boltz --

...

btw: Entnehme ich Deinen Worten, daß XP und Sicherheit in irgendeiner Weise eine Verbindung eingehen können? Klar können sie. eine logische XOR-Verbindung. [U. Ohse und S. Posner in dasr]

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Tim Edwards

10 Oct 10 Oct

10:55

New subject: [opensuse-factory] apparmor and dovecot (was: Re: 12.1 beta, apparmor not installed automatically)

On Monday, October 10, 2011 1:54 AM, "Christian Boltz" wrote:

...

...
Apparmor definitely did break my simple local-users only Dovecot setup though, and the bug I raised was closed as fixed even though it wasn't for me.

I guess you are talking about https://bugzilla.novell.com/show_bug.cgi?id=681267

Yes

...

I don't have the 11.4 profiles here at the moment (I'm using factory), so I can't check it right now.

But I'll help you to solve the problems you see ;-)

First check if you are using the profiles from the apparmor-profiles package or modified (maybe outdated) profiles: rpm -V apparmor-profiles

S.5....T. c /etc/apparmor.d/bin.ping S.5....T. c /etc/apparmor.d/sbin.klogd S.5....T. c /etc/apparmor.d/usr.lib.dovecot.deliver S.5....T. c /etc/apparmor.d/usr.lib.dovecot.dovecot-auth S.5....T. c /etc/apparmor.d/usr.lib.dovecot.imap S.5....T. c /etc/apparmor.d/usr.lib.dovecot.imap-login S.5....T. c /etc/apparmor.d/usr.lib.dovecot.managesieve-login S.5....T. c /etc/apparmor.d/usr.lib.dovecot.pop3 S.5....T. c /etc/apparmor.d/usr.lib.dovecot.pop3-login S.5....T. c /etc/apparmor.d/usr.sbin.avahi-daemon S.5....T. c /etc/apparmor.d/usr.sbin.dnsmasq S.5....T. c /etc/apparmor.d/usr.sbin.dovecot S.5....T. c /etc/apparmor.d/usr.sbin.nmbd S.5....T. c /etc/apparmor.d/usr.sbin.ntpd S.5....T. c /etc/apparmor.d/usr.sbin.smbd S.5....T. c /etc/apparmor.d/usr.sbin.traceroute

...

If you see anything related to dovecot in the output, please mv /etc/apparmor.d/*dovecot* /some/where/ zypper in -f apparmor-profiles rcapparmor reload

If you still see problems, please - switch the dovecot profiles to complain mode: aa-complain /etc/init.d/*dovecot* - run dovecot for some time - open a new bugreport and attach your audit.log.

It seems to be working now, although I still get this error: Oct 10 12:48:24 localhost kernel: [1375671.879183] type=1400 audit(1318243704.530:53): apparmor="DENIED" operation="open" parent=21582 profile="/usr/sbin/dovecot" name="/proc/21657/mounts" pid=21657 comm="dovecot" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Does the caching feature you were talking about earlier in the thread fix this need to move the profiles from /etc/apparmor.d/ for them to update properly?

...

...
Maybe, but after my experience with dovecot I got the impression that the Apparmor profiles weren't widely tested and were bitrotting. Maybe that's changed recently though.

The problem is that many programs behave different depending on their configuration and usage, which makes it hard to create a perfect profile.

To give you an example: traceroute (which is a quite simple program when compared to dovecot) had a good profile. Well, except if you used the -I flag... (see bug 685674)

But this example also shows that the profiles are not bitrotting ;-)

Ok, it looks like you guys are putting some effort into getting them to work.

...

...
...
Besides that, the default advice in this case should be "check /var/log/audit/audit.log and open a bugreport if needed".

It's not exactly user friendly. Can't it use the desktop notification thing (whatever it's called) to pop-up a notification when it blocks something?

aa-notify isn't started by default. If you want to use it, run sudo DISPLAY=$DISPLAY /usr/sbin/aa-notify -p

Unfortunately aa-notify is slightly broken in 11.4. If you want to use it, run chmod 750 /var/log/audit or install the packages from security:apparmor:factory. Factory already contains the working version.

BTW: the need for handing over $DISPLAY is caused by the very secure sudo config in openSUSE - it resets most environment variables. Maybe I get a more user-friendly way implemented upstream, but I'm afraid you'll always have to hand over $DISPLAY (or $DBUS_SESSION_BUS_ADDRESS) to aa-notify. Yes, I'm aware that this isn't a perfect solution, but it's the best I can offer for 12.1.

Nothing's perfect I guess, but it'd be better not to have it working in the background blocking things with no notifications. Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Christian Boltz

17:55

New subject: [opensuse-factory] apparmor and dovecot (was: Re: 12.1 beta, apparmor not installed automatically)

Hello, Am Montag, 10. Oktober 2011 schrieb Tim Edwards:

...

On Monday, October 10, 2011 1:54 AM, "Christian Boltz" wrote:

...

...
I guess you are talking about https://bugzilla.novell.com/show_bug.cgi?id=681267

Yes

...
I don't have the 11.4 profiles here at the moment (I'm using factory), so I can't check it right now.

But I'll help you to solve the problems you see ;-)

First check if you are using the profiles from the apparmor-profiles> package or modified (maybe outdated) profiles: rpm -V apparmor-profiles

S.5....T. c /etc/apparmor.d/bin.ping S.5....T. c /etc/apparmor.d/sbin.klogd S.5....T. c /etc/apparmor.d/usr.lib.dovecot.deliver S.5....T. c /etc/apparmor.d/usr.lib.dovecot.dovecot-auth S.5....T. c /etc/apparmor.d/usr.lib.dovecot.imap S.5....T. c /etc/apparmor.d/usr.lib.dovecot.imap-login S.5....T. c /etc/apparmor.d/usr.lib.dovecot.managesieve-login S.5....T. c /etc/apparmor.d/usr.lib.dovecot.pop3 S.5....T. c /etc/apparmor.d/usr.lib.dovecot.pop3-login S.5....T. c /etc/apparmor.d/usr.sbin.avahi-daemon S.5....T. c /etc/apparmor.d/usr.sbin.dnsmasq S.5....T. c /etc/apparmor.d/usr.sbin.dovecot S.5....T. c /etc/apparmor.d/usr.sbin.nmbd S.5....T. c /etc/apparmor.d/usr.sbin.ntpd S.5....T. c /etc/apparmor.d/usr.sbin.smbd S.5....T. c /etc/apparmor.d/usr.sbin.traceroute

Looks like you have lots of modified profiles, including those for dovecot.

...

...
If you see anything related to dovecot in the output, please

mv /etc/apparmor.d/*dovecot* /some/where/ zypper in -f apparmor-profiles rcapparmor reload

If you still see problems, please

- switch the dovecot profiles to complain mode: aa-complain /etc/init.d/*dovecot*

- run dovecot for some time - open a new bugreport and attach your audit.log.

It seems to be working now, although I still get this error: Oct 10 12:48:24 localhost kernel: [1375671.879183] type=1400 audit(1318243704.530:53): apparmor="DENIED" operation="open" parent=21582 profile="/usr/sbin/dovecot" name="/proc/21657/mounts" pid=21657 comm="dovecot" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Add /proc/[0-]*/mounts r, or @{PROC}/[0-9]*/mounts r, to the usr.sbin.dovecot profile to get rid of this error. I'll also send a patch upstream to include this rule (the @{PROC} variant).

...

Does the caching feature you were talking about earlier in the thread fix this need to move the profiles from /etc/apparmor.d/ for them to update properly?

That are two different things. a) rpm packaging The profiles are packaged as "%(config) %(noreplace)" in the apparmor- profiles package. This means rpm will never replace existing files if they are modified (like those rpm -V listed for you). Instead, you should get some *.rpmnew files with the new version. (Just for completeness: the apparmor initscript ignores *.rpmnew, *.rpmorig and some other "backup" files.) b) caching Caching means that a binary version of each profile is stored in the cache directory (/etc/apparmor.d/cache, which I made a symlink to /var/cache/apparmor/). If a profile is modified or added, apparmor_parser automatically (re)creates the cache file.

...

Ok, it looks like you guys are putting some effort into getting them to work.

Oh yes. I better don't count the hours I spent on AppArmor in the last months ;-)

...

...
aa-notify isn't started by default. If you want to use it, run

sudo DISPLAY=$DISPLAY /usr/sbin/aa-notify -p [...] Nothing's perfect I guess, but it'd be better not to have it working in the background blocking things with no notifications.

Feel free to allow password-less sudo for aa-notify and put it in your autostart folder ;-) Regards, Christian Boltz --

...

Aber der SuSE-Kernel wird mindestens ein Goodie haben, das auch du sehr zu schätzen wissen wirst. Er wird diesmal stabil laufen?? :-)) [> Philipp Thomas und Thomas Hertweck in suse-linux]

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Tim Edwards

11 Oct 11 Oct

08:28

New subject: [opensuse-factory] apparmor and dovecot (was: Re: 12.1 beta, apparmor not installed automatically)

On Monday, October 10, 2011 7:55 PM, "Christian Boltz" wrote:

...

Hello,

...
S.5....T. c /etc/apparmor.d/bin.ping S.5....T. c /etc/apparmor.d/sbin.klogd S.5....T. c /etc/apparmor.d/usr.lib.dovecot.deliver S.5....T. c /etc/apparmor.d/usr.lib.dovecot.dovecot-auth S.5....T. c /etc/apparmor.d/usr.lib.dovecot.imap S.5....T. c /etc/apparmor.d/usr.lib.dovecot.imap-login S.5....T. c /etc/apparmor.d/usr.lib.dovecot.managesieve-login S.5....T. c /etc/apparmor.d/usr.lib.dovecot.pop3 S.5....T. c /etc/apparmor.d/usr.lib.dovecot.pop3-login S.5....T. c /etc/apparmor.d/usr.sbin.avahi-daemon S.5....T. c /etc/apparmor.d/usr.sbin.dnsmasq S.5....T. c /etc/apparmor.d/usr.sbin.dovecot S.5....T. c /etc/apparmor.d/usr.sbin.nmbd S.5....T. c /etc/apparmor.d/usr.sbin.ntpd S.5....T. c /etc/apparmor.d/usr.sbin.smbd S.5....T. c /etc/apparmor.d/usr.sbin.traceroute

Looks like you have lots of modified profiles, including those for dovecot.

Which is strange, because I never modified any of them except the dovecot ones.

...

...
...
If you see anything related to dovecot in the output, please

mv /etc/apparmor.d/*dovecot* /some/where/ zypper in -f apparmor-profiles rcapparmor reload

If you still see problems, please

- switch the dovecot profiles to complain mode: aa-complain /etc/init.d/*dovecot*

- run dovecot for some time - open a new bugreport and attach your audit.log.

It seems to be working now, although I still get this error: Oct 10 12:48:24 localhost kernel: [1375671.879183] type=1400 audit(1318243704.530:53): apparmor="DENIED" operation="open" parent=21582 profile="/usr/sbin/dovecot" name="/proc/21657/mounts" pid=21657 comm="dovecot" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Add /proc/[0-]*/mounts r, or @{PROC}/[0-9]*/mounts r, to the usr.sbin.dovecot profile to get rid of this error. I'll also send a patch upstream to include this rule (the @{PROC} variant).

Ok thanks

...

...
Does the caching feature you were talking about earlier in the thread fix this need to move the profiles from /etc/apparmor.d/ for them to update properly?

That are two different things.

a) rpm packaging The profiles are packaged as "%(config) %(noreplace)" in the apparmor- profiles package. This means rpm will never replace existing files if they are modified (like those rpm -V listed for you). Instead, you should get some *.rpmnew files with the new version. (Just for completeness: the apparmor initscript ignores *.rpmnew, *.rpmorig and some other "backup" files.)

b) caching Caching means that a binary version of each profile is stored in the cache directory (/etc/apparmor.d/cache, which I made a symlink to /var/cache/apparmor/). If a profile is modified or added, apparmor_parser automatically (re)creates the cache file.

...
Ok, it looks like you guys are putting some effort into getting them to work.

Oh yes. I better don't count the hours I spent on AppArmor in the last months ;-)

...
...
aa-notify isn't started by default. If you want to use it, run

sudo DISPLAY=$DISPLAY /usr/sbin/aa-notify -p [...] Nothing's perfect I guess, but it'd be better not to have it working in the background blocking things with no notifications.

Feel free to allow password-less sudo for aa-notify and put it in your autostart folder ;-)

I meant more using the notification system already present in KDE (and I assume other desktops) :) No one wants an unecessary root process that duplicates functionality already in the desktop. Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Rosenauer

7 Oct 7 Oct

12:22

Hi, Am 07.10.2011 13:28, schrieb Christian Boltz:

...

...
Putting half-working profiles in Apparmor is not the way to go, otherwise soon 'Disable Apparmor' will become part of the standard troubleshooting advice on the Opensuse forum.

It isn't yet? That's good news and shows that the default profiles use sane rules ;-)

I only used apparmor explicitely once in the past (on the desktop!) to confine skype but I never disabled it and it never got into my way up to now. So if it's maintained (which is) and gives some extra protection with the default rules (hope so but I haven't checked the profiles for a while) I'd vote for having it by default. A bonus would be if there is or will be a good way to find out when apparmor blocks something (aa-notify is apparently not very mature yet?). Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Claudio Freire

14:27

On Fri, Oct 7, 2011 at 8:28 AM, Christian Boltz wrote:

...

Basically all programs with a "save as..." menu item are impossible to profile because you never know where a user wants to store his files. Well, you could allow write access everywhere, but that doesn't really bring a security improvement.

There is an option, though, which is explicitly prohibit access to sensitive files. Like /etc/shadow, ~/.ssh, etc etc... It would stop many attack vectors. Of course, research would be needed to find out which attack vectors use which files, to make sure the profile is useful. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Christian Boltz

11:31

Hello, Am Freitag, 7. Oktober 2011 schrieb Tim Edwards:

...

I might have read your post wrong but are you saying that Apparmor willl, by default, break the file/folder sharing feature built into KDE?

...

This IMHO is completely wrong, you don't enhance security by simply breaking features, especially the most user-facing ones that are there in the GUI.

...

IIRC Redhat was very careful not to deploy profiles for services in SELinux until they were well tested and work.

...

Putting half-working profiles in Apparmor is not the way to go, otherwise soon 'Disable Apparmor' will become part of the standard troubleshooting advice on the Opensuse forum.

...

Can I get some more info from the machine? 'dmesg', 'cat /proc/bus/input/devices', etc ... Sorry, there's no command calles "etc" on my machine... ;-) [Rasmus Plewe on https://bugzilla.novell.com/show_bug.cgi?id=176022] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Lars Müller

14:01

Hi Christian, On Fri, Oct 07, 2011 at 03:07:27AM +0200, Christian Boltz wrote:

...

am Donnerstag, 6. Oktober 2011 schrieb Lars Müller:

[ 8< ]

...

...
Can't we populate the apparmor cache as part of the installation/ upgrade/ maintenance of the system?

I'll enable caching, see my reply to Coolo's mail for details.

However I don't want to package the cached files because that might cause funny side effects on updates (profile changed locally, but packaged cache looks newer and such stuff).

I aggree. Packaging the cached files would be the wrog approach. What I had in mind is forcing a (re)build of the AA cache as part of the installation workflow. Or as part of software install. Or with other worfs: keep it away from the boot process. Even better have it ready when we boot. There aren't so many cases when the profiles need to be rebuid: a) After an update _if_ the location of a binary changed or one got added. b) Newly installed software. Then we need for the new binaries a rebuild.

...

...
AA caused issues to Samba in the past. Nevertheless I like to have it enabled by default again. With profiles wher we're not sure if they work correctly we might run it in complain mode.

That might be an option, but I'm not really happy with shipping profiles in complain mode - users probably expect that all profiles are in enforce mode.

Yes. You're right.

...

IMHO the better way is to ship them in the "extras" profile directory /etc/apparmor/profiles/extras/ where aa-genprof will pick them up as template.

That said: There's a better solution for the samba profile, see below.

...
This reminds me to the open issue we had discussed in the past with regard to Samba, YaST, AA, and newly added shares. \:

Indeed, I'm aware of https://bugzilla.novell.com/show_bug.cgi?id=688040

The quick and easy solution would be a little script that extracts the paths of all shares from smb.conf and writes an apparmor profile sniplet. This script should run when starting and reloading samba.

The downside is that it won't be aware of everything because - you can reload samba using SWAT instead of the initscript or systemd

I would ignore SWAT atm. We should have removed this old code from the packages. Not only to save us the extra work we had with the recent security update.

...

- it's possible to add "dynamic" shares that don't show up in smb.conf (for example using the "share directory" feature in KDE)

Which utilizes "net usershare" IIRC. "net usershare: usershares are currently disabled" is what I get on a default install. I know, there is an easy way to enable it from inside YaST and therefore we have to care about it. Uhh, ahh, it's broken in 3.6 anyway. https://bugzilla.samba.org/show_bug.cgi?id=8511

...

Covering all this makes things really difficult, therefore I'd say we should at least do the easy part (based on smb.conf) for 12.1. That's much better than the current state and will probably cover most usecases.

Yes.

...

If someone can provide a script that prints the path of all shares in smb.conf (there are some hints about python and perl modules to parse smb.conf in the bugreport) in the format given below I'll then integrate it in the initscript and systemd service file.

This is how the apparmor profile sniplet should look like:

# autogenerated at samba startup - do not edit! /path/to/share/ rk, /path/to/share/** lrwk, /another/share/ rk, /another/share/** lrwk,

Or an enhanced testparm allowing us to define which parameter(s) to display would be nice. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Christian Boltz

9 Oct 9 Oct

21:28

Hello, Am Freitag, 7. Oktober 2011 schrieb Lars Müller:

...

On Fri, Oct 07, 2011 at 03:07:27AM +0200, Christian Boltz wrote:

...
am Donnerstag, 6. Oktober 2011 schrieb Lars Müller:

...

...
I'll enable caching, see my reply to Coolo's mail for details.

However I don't want to package the cached files because that might cause funny side effects on updates (profile changed locally, but packaged cache looks newer and such stuff).

I aggree. Packaging the cached files would be the wrog approach.

What I had in mind is forcing a (re)build of the AA cache as part of the installation workflow. Or as part of software install.

Or with other worfs: keep it away from the boot process. Even better have it ready when we boot.

That would make things really different - in theory I could do it in %post, but this will become really funny on new installations (as in --root=/mnt from rpm POV). And all this just to save 10s on the first boot after a new installation or an update? There are more important things where I can spend my time on, for example the script at the end of this mail...

...

There aren't so many cases when the profiles need to be rebuid:

a) After an update _if_ the location of a binary changed or one got added. b) Newly installed software. Then we need for the new binaries a rebuild.

c) if a profile was changed The good thing is: apparmor_parser automatically rebuilds the cache if a profile has been changed or added.

...

...
...
This reminds me to the open issue we had discussed in the past with regard to Samba, YaST, AA, and newly added shares. \: Indeed, I'm aware of https://bugzilla.novell.com/show_bug.cgi?id=688040

The quick and easy solution would be a little script that extracts the paths of all shares from smb.conf and writes an apparmor profile sniplet. This script should run when starting and reloading samba.

The downside is that it won't be aware of everything because - you can reload samba using SWAT instead of the initscript or systemd

...

I would ignore SWAT atm. We should have removed this old code from the packages. Not only to save us the extra work we had with the recent security update.

;-)

...

...
- it's possible to add "dynamic" shares that don't show up in smb.conf> (for example using the "share directory" feature in KDE)

Which utilizes "net usershare" IIRC.

"net usershare: usershares are currently disabled" is what I get on a default install. I know, there is an easy way to enable it from inside YaST and therefore we have to care about it.

Uhh, ahh, it's broken in 3.6 anyway. https://bugzilla.samba.org/show_bug.cgi?id=8511

<BOfH> OK, so we can ignore them for now ;-) </BOfH>

...

...
Covering all this makes things really difficult, therefore I'd say we should at least do the easy part (based on smb.conf) for 12.1. That's much better than the current state and will probably cover most usecases.

Yes.

...
If someone can provide a script that prints the path of all shares in smb.conf (there are some hints about python and perl modules to parse smb.conf in the bugreport) in the format given below I'll then integrate it in the initscript and systemd service file.

This is how the apparmor profile sniplet should look like: # autogenerated at samba startup - do not edit! /path/to/share/ rk, /path/to/share/** lrwk, /another/share/ rk, /another/share/** lrwk,

Or an enhanced testparm allowing us to define which parameter(s) to display would be nice.

testparm looks like a very good hint :-) You mean something like this? testparm -s 2>/dev/null | sed -n '/^[ \t]*path[ \t]*=[ \t]*[^% \t][^%][^%]*$/ s/^[ \t]*path[ \t]*=[ \t]*//p' Basically, the sed command prints all path= lines except paths that contain a % sign (for example %H in the [profiles] section). It also enforces a minimum path length of 2 bytes - if someone is insane enough to share /, he'll need to update the profile himself. For the default smb.conf, this gives me: /home /home/groups /var/tmp /var/lib/samba/drivers Now we need to change this to a format that AppArmor understands: echo '# autogenerated at samba start - do not edit!' testparm -s 2>/dev/null |sed -n '/^[ \t]*path[ \t]*=[ \t]*[^% \t]\{2,\}/ s§^[ \t]*path[ \t]*=[ \t]*$.*$$§\1/ rk,\n\1/** rwkl,§p' (did I already mention that I like sed? ;-) Result: # autogenerated at samba start - do not edit! /home/ rk, /home/** rwkl, /home/groups/ rk, /home/groups/** rwkl, /var/tmp/ rk, /var/tmp/** rwkl, /var/lib/samba/drivers/ rk, /var/lib/samba/drivers/** rwkl, Does this look good so far? If yes, I can add the code needed to reload the apparmor profile (and to avoid superfluous profile reloads if nothing was changed). Gruß Christian Boltz --

...

got a patch? -ENOTMYJOB [> Markus Rueckert and Bernhard Walle in opensuse-packaging]

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Meissner

20:44

On Thu, Oct 06, 2011 at 12:44:18PM +0200, Ludwig Nussel wrote:

...

Stephan Kulow wrote:

...
Am Donnerstag, 6. Oktober 2011 schrieb Ludwig Nussel:

...
No doubt about that. I was baffled when I noticed the installed profiles are mostly useless in a default install and the init script dog slow (see also bnc#689458). Who is 'we' though? I would have expected that the security team is asked before changing security features of the distribution.

I had the impression you and Marcus at least are part of this list. http://lists.suse.de/opensuse-factory/2011-08/msg00345.html triggered no response and as such Sascha changed the patterns.

I don't read each and every mail esp if the subject seems uninteresting.

Yes, the mail also escaped my notice. That the Samba profiles caused so much grief is bad, I would have advised against including them actually given that samba can share from anyware. That Christian has taken up the maintenance of the profiles now is a good thing in that regard. A brief query in IRC or even on the floor would have been appreciated before doing such changes. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Tim Edwards

6 Oct 6 Oct

10:57

On Thursday, October 06, 2011 11:33 AM, "Stephan Kulow" wrote:

...

Am Donnerstag, 6. Oktober 2011 schrieb Tim Edwards:

...
On Thursday, October 06, 2011 10:42 AM, "Stephan Kulow"

wrote:

...
Am Mittwoch, 5. Oktober 2011 schrieb Dieter Werner:

...
Hi,

I installed 12.1 beta x86_64 with KDE in kvm as a fresh install I basically used the default settings. I noticed the following:

- no apparmor package was installed is it not longer used in 12.1?

That's true. It's still on DVD though.

What replaces it in 12.1? Or is it just not needed on the kind of systems (mostly desktop, laptop) that Opensuse is intended to be used on? We never had apparmor in real use by default. If you wanted to secure your system, you had to do manual work. And now we added one more step for those: install apparmor pattern. For everyone else, the system is faster.

Sounds sensible, it only ever caused problems for me (yes I did file a bug :)) so leaving it off by default means only people who really want to go through the steps of configuring it have to deal with it. I just ended up disabling it on my systems. Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Christian Boltz

7 Oct 7 Oct

00:42

Hello, (I'm just recovering from some KMail/Akonadi migration "fun" (bug 721931) and currently use IMAP until everything works again - is the migration tool really considered production-ready?) am Donnerstag, 6. Oktober 2011 schrieb Stephan Kulow:

...

Am Donnerstag, 6. Oktober 2011 schrieb Tim Edwards:

...
What replaces it in 12.1? Or is it just not needed on the kind of systems (mostly desktop, laptop) that Opensuse is intended to be used on?

We never had apparmor in real use by default. If you wanted to secure your system, you had to do manual work.

I'm sorry to say that, but you are wrong ;-) There are not too many profiles installed by default, but the maintainers of at least two programs/packages already complained about the now missing apparmor protection: - Peter Czanik / syslog-ng - see http://195.135.221.135/opensuse-factory/2011-09/msg00745.html - Lars Müller / samba (in this thread) - (and AJ at least cares about the profile for nscd) Those examples already show something important: syslog-ng and nscd are running on every installation. I don't have to tell you that nscd handles DNS queries and therefore network traffic. Having it protected is always a good idea. And: yes, I'd call that "in real use". Maybe the maintainers of ping and traceroute don't really care if they get some extra protection or not, but those programs also handle network traffic and are potentially endangered by faked/malicious traffic. All this protection was available _by default_, without manual work. There were also several users who complained that apparmor is no longer installed by default, but I'm too tired to google the archive links for those mails ;-)

...

And now we added one more step for those: install apparmor pattern. For everyone else, the system is faster.

... and less secure :-( Maybe it saves a bit of boot time, but AFAIK there isn't a measureable performance impact in the running system. Oh, and loading the apparmor profiles at boot will become much faster with my next commit of the apparmor package because I'll enable caching. The cache will be written at the first start of apparmor (and whenever a profile was changed). To give you some numbers, I measured this with "time rcapparmor reload" on my system: - without caching: 7.5s - enable caching, first start (= write the cache): 10s - restart with cache filled: 0.3 to 0.4s In other words: The startup time for apparmor will see a massive 2000% speedup in the next days. See https://bugzilla.novell.com/show_bug.cgi?id=689458 for all the technical details. To avoid another mail, I'll quote some text from another mail you sent: Am Donnerstag, 6. Oktober 2011 schrieb Stephan Kulow:

...

I had the impression you and Marcus at least are part of this list. http://lists.suse.de/opensuse-factory/2011-08/msg00345.html triggered no response and as such Sascha changed the patterns.

I assume "no response" was meant as "no response from the security team" because otherwise you'd have missed lots of mails, for example http://lists.suse.de/opensuse-factory/2011-08/msg00391.html and various replies to it.

...

And at that point, Jeff was basically saying that he does not maintain appamor and the security team didn't care that it was bitrotting either.

Yes, but I replied and stepped up. Initially my plan was to "only" upstream the openSUSE patches to make maintenance easier for Jeff, but then I completely took over the package. This also fixes the problem with the bitrotting apparmor package, so please re-add it to default pattern! Oh, BTW: can you make me the default assignee for AppArmor in bugzilla, please? Gruß Christian Boltz -- Jetzt warte ich noch ein paar Wochen, bis die neue Version 10.1 herauskommt, höre mir die Schreie der Early-Adopters an, und überlege dann, ob ich bis 10.2 warte, lieber die 10.0 installiere oder doch jetzt die 10.1 nehme... [Sandy Dobic in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Peter Czanik

06:28

Hello, On 10/07/2011 02:42 AM, Christian Boltz wrote:

...

...
And now we added one more step for those: install apparmor pattern. For everyone else, the system is faster. ... and less secure :-(

Maybe it saves a bit of boot time, but AFAIK there isn't a measureable performance impact in the running system.

At least nothing I could measure with apache and syslog-ng...

...

Oh, and loading the apparmor profiles at boot will become much faster with my next commit of the apparmor package because I'll enable caching. The cache will be written at the first start of apparmor (and whenever a profile was changed). Wow, that would be great! I really would like to have AppArmor back enabled by default! Let us know, when there is anything to test!

Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

4583

Age (days ago)

4589

Last active (days ago)

List overview

Download

27 comments

12 participants

participants (12)

C
Christian Boltz
Claudio Freire
Dieter Werner
Lars Müller
Ludwig Nussel
Marcus Meissner
Peter Czanik
Sascha Peilicke
Stephan Kulow
Tim Edwards
Wolfgang Rosenauer