The Linux security model is the same as Windows and OSX. Your ACLs are based on Users and Groups. If an attacker gains access to a process with User ID 100 it is the assumption that the entire User ID is compromised. This is the model of separation. This is in contrast to a security model similar to that of Android where every app is separate from another app (intents being the IPC that bridges apps). Android actually does use separate user accounts for security reasons as well but the central security model is that each app gets its own set of rights and abilities as opposed to each user group.

Neither is ‘right’ and both are compatible. They keep things separated and that’s all good.

The issue comes with X. The X Window System provides a Graphic User Interface (GUI) for many Linux distros including Ubuntu 12.04. X (or X11) bridges the gap between separated users and groups. A process in User ID 100 can both send and receive input to a process in User ID 0 or 5 or 50 or whichever. It breaks the model of separation.

Let’s say I’m running a graphic program such as Pidgin. Pidgin is running in its own separate UID and it’s in an apparmor profile that’s enforced. I then have Xchat running as a separate user and it’s also confined within apparmor. I also have Firefox running in the Pidgin UID.

As an attacker I gain access to Pidgin. I’m now restricted through Apparmor and I can only access the files available to the UID. Because of Apparmor I can’t touch Firefox’s files but I can interact with it through X, sending and receiving keys. I’m actually alright with this.

The issue is that I can also, from Pidgin, use X to send and receive keys to Xchat. That’s not ok – whereas Firefox and Pidgin share a UID Xchat does not and interaction like this should not be allowed without root.

Basically, X should be split into sessions (or treat it as if it were a separate session) based on users/ groups and global hotkeys should require root . I’m not sure how possible this is but the idea is that users can access keystrokes but separate users should not be allowed to.

Until this is solved there is a massive hole in every Linux users system – you can use grsecurity, PaX, apparmor, whatever and if an attacker so much as gets shell in a process they can potentially do whatever they want. SELinux provides a potential solution but ultimately this is a design flaw that needs to be handled at the design level.