Re: AppArmor FAQ

Crispin Cowan wrote:
David Wagner wrote:
James Morris wrote:
[...] you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc.
[...]
Just look at their code and their own description of AppArmor.
My gosh, you're right. What the heck? With all due respect to the
developers of AppArmor, I can't help thinking that that's pretty lame.
I think this raises substantial questions about the value of AppArmor.
What is the point of having a jail if it leaves gaping holes that
malicious code could use to escape?

And why isn't this documented clearly, with the implications fully
explained?

I would like to hear the AppArmor developers defend this design decision.
It was a simplicity trade off at the time, when AppArmor was mostly
aimed at servers, and there was no HAL or DBUS. Now it is definitely a
limitation that we are addressing. We are working on a mediation system
for what kind of IPC a confined process can do
http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html

Except servers use IPC and need this access control as well. Without IPC and network restrictions you can't protect database servers, ldap servers, print servers, ssh agents, virus scanning servers, spam scanning servers, etc from attackers with knowledge of how to abuse the IPC.
When our IPC mediation system is code instead of vapor, it will also
appear here for review. Meanwhile, AppArmor does not make IPC security
any worse, confined processes are still subject to the usual Linux IPC
restrictions. AppArmor actually makes the IPC situation somewhat more
secure than stock Linux, e.g. normal DBUS deployment can be controlled
through file access permissions. But we are not claiming AppArmor to be
an IPC security enhancement, yet.
Without a security interface in DBUS similar to SELinux' apparmor won't be able to control who can talk to who across DBUS, only who can connect to DBUS directly.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: AppArmor FAQ
    ... IPC, shared memory, Unix domain sockets, local IP networking, ... remote networking etc. ... I think this raises substantial questions about the value of AppArmor. ... When our IPC mediation system is code instead of vapor, ...
    (Linux-Kernel)
  • Re: AppArmor FAQ
    ... policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. ... I think this raises substantial questions about the value of AppArmor. ... The native abstraction for shared memory would be the key used when creating the shared memory segment. ...
    (Linux-Kernel)
  • Re: [PATCH 1/6] staging: android: binder: Remove some funny && usage
    ... Did Google evaluate DBus at all? ... replacement for the binder. ... If Google believes the binder is the right solution for IPC, ...
    (Linux-Kernel)
  • Re: The server is not configured for transactions !!?!?!?
    ... Arty made a post then I commented below ... > After attack to virus NetSky.xx the servers do not share IPC$... ... > 2 minuts the IPC$ goes down, also if i force NetShare IPC$. ... Microsoft Windows MVP - Windows Server - Directory Services ...
    (microsoft.public.win2000.active_directory)
  • Re: svchosting.exe -> Backdoor.Sdbot
    ... Network came to a hault. ... > servers won't show their IPC$ shares. ... MVP Security - Windows ...
    (microsoft.public.security.virus)
Loading