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]