[opensuse-security] Proper AppArmor profiles
Hi there, do you know a good source for working, proper AppArmor profiles? I am especially looking for a good Firefox and Thunderbird profile. Thanks -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Hello, Am Samstag, 16. August 2014 schrieb pinguin74:
do you know a good source for working, proper AppArmor profiles?
I am especially looking for a good Firefox and Thunderbird profile.
I guess you already found the apparmor-profiles package ;-) and probably noticed that it also contains some additional (rarely tested) profiles in /etc/apparmor/profiles/extras/ [1] (including a profile for firefox, but I'm afraid it's terribly outdated). aa-genprof will also offer the profiles from the extras directory as base. Besides that, you might want to have a look at the profiles Ubuntu ships. You can find them at http://bazaar.launchpad.net/~apparmor-dev/apparmor-profiles/master/files/hea... but some of the profiles are "hidden" inside the packages, so you'll have to extract them from the *.deb or the package sources on launchpad [2]. Note: I never tested the Ubuntu profiles on openSUSE - they are probably a good start, but you'll need to make some adjustments. Regards, Christian Boltz [1] starting with AppArmor 2.9, the extra profiles will be in /usr/share/apparmor/extra-profiles/ [2] I know this is far from ideal, and discussed this with some Ubuntu people (who are also working on upstream AppArmor) more than once. Unfortunately we don't have a good solution yet :-( PS: random sig ;-) -- <cboltz> jjohansen: we can just label it "the can't be more broken than 2.8.3 release" ;-) <jjohansen> cboltz: no, with a name like that murphy is bound to strike [from #apparmor] -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
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. I used the program, did some things in order to trigger AppArmor messages and events. Afterwards in invoke aa-logprof. I thought aa-logprof gives me the opportunity to tune the newly created profile when you press (S)can. But nothing happened.... I hoped to get some questions from AA whether to allow or block certain events, but that did not happen.... 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?
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
Holy crap, auditd wasn´t running. Fixed now, AA works. Great. I love it, AA is so simple to set up. But, some questions left: q1) Some apps want to access /proc/ and the directory that corresponds to the process ID. How do you handle that? E.g. vlc wants to access /proc/4672/status where 4672 is the current process ID. I do not want to give read access to the complete /proc tree, what AA just did. How do you determine the current process ID? Is there a variable generated automatically? Like $HOME? q2) How do you automatically detect suspicous behaviour? In other words, do you look at the logs for DENIED messages every 10 minutes? I consider to have some script that gives me a desktop popup notification if a DENIED message occured. I think to detect suspicious things you need automatic notifications. q3) If you confine, say a webbrowser all plugins become child proceses, right? Thus the flash plugin becomes a child process inheriting the profile rules, right? Thus, the same applies to malicious code an attacker tries to inject? If an attacker injects $BADSTUFF it becomes a child process, inheriting the profile rules, right? Thus, wouldn´t observing for new child processes contribute to detect attacks? I hope it´s okay to pour this many questions here ;-) You mentioned something about much time you have, or so.... ;-)
Hello, Am Mittwoch, 20. August 2014 schrieb pinguin74:
Holy crap, auditd wasn´t running. Fixed now, AA works. Great.
I love it, AA is so simple to set up.
But, some questions left:
q1)
Some apps want to access /proc/ and the directory that corresponds to the process ID. How do you handle that? E.g. vlc wants to access /proc/4672/status where 4672 is the current process ID. I do not want to give read access to the complete /proc tree, what AA just did. How do you determine the current process ID? Is there a variable generated automatically? Like $HOME?
No(t yet), but there are plans to do so. You can use /proc/@{PID}/ - currently it allows any pid, but the plan is to restrict it to the current process' pid in the future. You can also add the "owner" keyword to restrict the rule to processes running by the current user.
q2)
How do you automatically detect suspicous behaviour? In other words, do you look at the logs for DENIED messages every 10 minutes? I consider to have some script that gives me a desktop popup notification if a DENIED message occured. I think to detect suspicious things you need automatic notifications.
Have a look at aa-notify ;-) sudo aa-notify -p --display $DISPLAY The alternative is to run aa-notify -s 1 -v | mail -s "AppArmor events" root in a daily cronjob. (See aa-notify --help for an explanation what the parameters do.)
q3)
If you confine, say a webbrowser all plugins become child proceses, right? Thus the flash plugin becomes a child process inheriting the profile rules, right? Thus, the same applies to malicious code an attacker tries to inject? If an attacker injects $BADSTUFF it becomes a child process, inheriting the profile rules, right? Thus, wouldn´t observing for new child processes contribute to detect attacks?
If plugins run as child processes (depends on the implementation in the browser), they'll need execute permissions in the browser's profile. This means you can switch to a separate profile (Px) or child profile (Cx). Also, as usual, AppArmor does only allow what you write into the profile, so it won't allow to execute something that isn't allowed in the profile. As a starting point, I'm attaching my profile for firefox plugin- container - without any warranty ;-) Note that this profile is not really "nice" and far from something that I'd include in the official package. For example, it contains quite some hardcoded version numbers etc. and will therefore break with the next update. Also note that it contains "lib64" at several places - you'll need to change it if you want to use it on non-64bit systems. Regards, Christian Boltz -- We should actually check if the installation via braille still works. OTOH, it is a tradition that it's always broken by a late RC due to color scheme changes... :-) [Stefan Seyfried in opensuse-factory]
Hellooo,
q1)
Some apps want to access /proc/ and the directory that corresponds to the process ID. How do you handle that?
No(t yet), but there are plans to do so.
I think the best way would be to allow shell commands from within profiles. AppArmor could include an additional config file that defines a set of shell commands allowed in profile files. I think that would be nice. Maybe you can write a wrapper for the PID issue, but I have no good idea yet.
q2)
How do you automatically detect suspicous behaviour?
Have a look at aa-notify ;-)
Great. So far I have an open terminal running tail -f When I look in your example profile, I see Cx somewhere and you define the profile for the child process within the main profile file, right? Thus you don´t need several profile files, you can put the child´s profile right into the main profile file, right? Thanks BTW, sending a user agent with your mail user client may not be beneficial for security....
Hello, Am Donnerstag, 21. August 2014 schrieb pinguin74:
q1)
Some apps want to access /proc/ and the directory that corresponds to the process ID. How do you handle that?
No(t yet), but there are plans to do so.
I think the best way would be to allow shell commands from within profiles. AppArmor could include an additional config file that defines a set of shell commands allowed in profile files. I think that would be nice. Maybe you can write a wrapper for the PID issue, but I have no good idea yet.
Well, this isn't as easy as it looks ;-) You can write scripts that automatically update a profile (or profile sniplet) - that's what I did for samba to adopt the profile to the shares in smb.conf [1]. You'll of course need to be careful to avoid creating insecure sniplets. For PIDs, it's more interesting[tm] because it needs to be handled inside the kernel - the profile itsself can't know which PID a process gets at startup or when forking. A very ugly workaround would be to update the profile each time you start an application with the list of current PIDs. That's not what you want, trust me ;-)
When I look in your example profile, I see Cx somewhere and you define the profile for the child process within the main profile file, right? Thus you don´t need several profile files, you can put the child´s profile right into the main profile file, right?
Basically right. The more important part is that a child profile is only used when the child is executed by the parent - but not when you execute the child from another program. So for example if you have /usr/bin/firefox { /bin/foo Cx, [...] } /bin/foo will only be confined if it's called by firefox. It will run unconfined if you start it from a shell or from another program. BTW: You might want to have a look at - http://blog.cboltz.de/archives/65-openSUSE-conference.html - especially the "AppArmor Crash Course" slides linked at the end - http://activedoc.opensuse.org/book/opensuse-security-guide/part-iv-confining...
BTW, sending a user agent with your mail user client may not be beneficial for security....
Who tells you that my header contains the user agent I'm actually using? ;-) Besides that, experts can often tell from small details in the other headers which mail client was used. Oh, and finally - I'm quite sure KMail does not have critical security issues (with HTML mode disabled). Maybe I'm just not paranoid enough to remove that header ;-) Regards, Christian Boltz PS: Non-random sig ;-) [1] /usr/share/samba/update-apparmor-samba-profile -- my_hdr X-MSMail-Priority: Normal my_hdr X-Mailer: Microsoft Outlook Express 5.50.4133.2400 my_hdr X-MimeOLE: Produced by Microsoft MimeOLE V5.50.4133.2400 unset user_agent set attribution="----- Original Message -----\n\From: %n <%a>\n\%t\n\Sent: %d\n\Subject: %s" ...und schon benutzt man OE. Mach das mal mit KMail. ;-)))) [Andreas Kneib über mutt in suse-linux] -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
When I look in your example profile, I see Cx somewhere and you define the profile for the child process within the main profile file, right? Thus you don´t need several profile files, you can put the child´s profile right into the main profile file, right?
Basically right.
When using Px or px you have to crate a seperate profile file for the corresponding application, right? This way, the application is always confined, no matter if called from within another profile or invoked solely, right? For example I plan to confine gpg, thus it would be easier to use px and create a seperate gpg profile that can be called from within other profiles, right?
BTW, sending a user agent with your mail user client may not be beneficial for security....
Who tells you that my header contains the user agent I'm actually using? ;-)
Indeed! You passed this test ;-)
Besides that, experts can often tell from small details in the other headers which mail client was used. Oh, and finally - I'm quite sure KMail does not have critical security issues (with HTML mode disabled). Maybe I'm just not paranoid enough to remove that header ;-)
"They" will always find holes to penetrate your system. Whoever "they" might be. This is, why God (and SUSE) give us AppArmor :-)
Hello, Am Sonntag, 24. August 2014 schrieb pinguin74:
When I look in your example profile, I see Cx somewhere and you define the profile for the child process within the main profile file, right? Thus you don´t need several profile files, you can put the child´s profile right into the main profile file, right?
Basically right.
When using Px or px you have to crate a seperate profile file for the corresponding application, right? This way, the application is always confined, no matter if called from within another profile or invoked solely, right?
Exactly.
For example I plan to confine gpg, thus it would be easier to use px and create a seperate gpg profile that can be called from within other profiles, right?
Correct. (However you should prefer Px over px to get environment variables like LD_PRELOAD etc. cleaned.) Regards, Christian Boltz -- Aber genauso können mir ja auch die Grünen leid tuen. Da bin ich doch lieber blau ... [Konrad Neitzel in suse-linux] -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
For example I plan to confine gpg, thus it would be easier to use px and create a seperate gpg profile that can be called from within other profiles, right?
Correct. (However you should prefer Px over px to get environment variables like LD_PRELOAD etc. cleaned.)
What is the default behaviour of AA, does it clean variables when using "rix" for example? Thanks
Hello, Am Montag, 25. August 2014 schrieb pinguin74:
For example I plan to confine gpg, thus it would be easier to use px and create a seperate gpg profile that can be called from within other profiles, right?
Correct. (However you should prefer Px over px to get environment variables like LD_PRELOAD etc. cleaned.)
What is the default behaviour of AA, does it clean variables when using "rix" for example?
AppArmor cleans environment variables when using an _uppercase_ *x rule (Px, Cx, Ux). ix is only available in lowercase, which also means the environment isn't cleaned when using ix. (Same for px, cx and ux.) Regards, Christian Boltz -- After a little bit of thinking* [...] * yes, I do it sometimes and yes, it usually hurts and leads to bad stuff, I'll try not to do it again [Jos Poortvliet in opensuse-factory] -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
participants (2)
-
Christian Boltz -
pinguin74