Hello, Am Dienstag, 19. August 2014 schrieb pinguin74:
I have some trouble with aa-genprof and aa-logprof. Didn´t know whether to start new thread....
Ok, I started invoking aa-genprof thunderbird.
Now, a more or less empty new profile was written.
Just to be sure: you have to start thunderbird _after_ invoking aa-genprof. Technical details: - aa-genprof creates a nearly-empty profile - aa-genprof loads this profile into the kernel (in complain mode) - when you start thunderbird _afterwards_, it will use this nearly-empty profile and log whatever it needs to access Note that newly loaded profiles won't be applied to running processes - they continue to run unconfined. This means: if you started thunderbird _before_ invoking aa-genprof, it won't use the profile and you'll get an empty log. (If a program is already running with an AppArmor profile, you can of course use "rcapparmor reload" to load a newer profile, which will then be used by the running process.)
I hoped to get some questions from AA whether to allow or block certain events, but that did not happen....
See above - my guess is that you started thunderbird before invoking aa-genprof. Another (less likely) option is that you have two thunderbird binaries in different locations, and aa-genprof picked the wrong one. (You can use the full path to avoid this.) Oh, another candidate is logging in general - you'll need auditd or traditional syslog. Journald logs are not supported (exporting them as plaintext to a file and using aa-logprof -f the-logfile.txt should work)
Oh and if I remember correctly years ago in openSUSE there was a YaST2 GUI module for creating new AA profiles. That seem to be gone. The current YaST2 module for AA is a crippled thing that merely allows basic things.
Obviously AA seeem to be a dead thing for openSUSE?
Yes and no. (TL;DR summary: scroll down to "To sum it up" ;-) The YaST module indeed needs some love. The problem with the removed parts is that the YaST module is based on the upstream perl code, which is in maintenance mode and quite hard to maintain because, well, it grew over years, and perl can be(come) quite cryptic ;-) This also means the YaST module is (probably - I never looked into the code) hard to maintain. New versions of AppArmor (starting with 2.9) will contain python-based tools (a full rewrite, written during GSoC last year [1]) and include some new features and lots of bugfixes[2]. While this is a good thing for AppArmor, it also means that the YaST module will need to be migrated to the python-based tools. (If someone wants to work on it, I can help on the AppArmor side to make it as easy and future-proof as possible on the YaST side.) Oh, BTW - who needs YaST if he has commandline tools? ;-) For AppArmor, the main thing that YaST did is replacing keyboard input (press "a" for "allow") with a mouse click on the "allow" button ;-) IMHO that's superfluous, but your milage may vary. That all said - the AppArmor package in openSUSE is actively maintained (by me ;-) and got quite some profile additions and updates [3] since I'm maintaining it. In the meantime, it got quite boring ;-) [4] because I rarely receive a bugreport. If you notice any problem, open a bugreport! (Asking on this mailinglist will also work.) BTW: SUSE is also still interested in AppArmor. I know they did a major update for the AppArmor chapter in the SLE 12 manual [5]. It's already available as XML in SVN [6] and hopefully will also be merged into the openSUSE manuals. To sum it up: AppArmor in openSUSE is definitively not a "dead thing" - but the YaST module is ill ;-) and really needs some love and medicine. Regards, Christian Boltz PS: non-random sig ;-) [7] [1] in one of the openSUSE slots, just in case you wonder if openSUSE is still interested in AppArmor ;-) [2] Just as an example - I spent several hours last sunday to hunt down a long-standing bug in aa-logprof and now at least have a proof-of- concept patch. See https://bugs.launchpad.net/apparmor/+bug/1014304 if you are interested in the details. [3] Just some examples: - I wrote a script to automatically adopt the samba profile to your shares defined in smb.conf - basically that solved all "AppArmor breaks samba" bugreports - I added a full set of profiles for dovecot 2.x - also, package maintainers care for the profiles - often they tell me when they need profile changes. Some even add additional profiles to their package - oh, and I flooded the upstream mailinglist with all the patches from the openSUSE package when I took over the package maintenance. That was a good method to get commit access ;-) and made the package maintenance easier. Also, users of other distributions now benefit from those patches. [4] To avoid I'm getting too bored ;-) I'm also working on upstream AppArmor, mostly on the aa-* tools and the profiles. [5] I did the proofreading - now the documentation team (especially Tomáš ;-) probably hates me *eg* [6] svn co https://svn.opensuse.org/svn/opensuse-doc/trunk/documents/sle/en [7] in german, sorry -- Gibt es ein Buch über das maßvolle Verwenden von Fußnoten? Wenn ja, dann bin ich bereit, Dir ein Exemplar zu schicken. [Thorsten Haude zu David Haller in sl-etikette] -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org