Security Model

[roddhjav]

This is the general discussion place for the new security model section from http://apparmor.pujol.io/security

As the formalization of this model is still a work in progress, feel free to provide feedbacks, comments and requirements

[valoq]

This looks like a broad yet useful approach to the topic. I think the security model should focus on describing the process boundary as the primary barrier where apparmor comes into play.
The threat model imho is a compromised/malicious process and the objective is to limit impact by isolating the process.

There are a few things I would like to see as part of the entire threat model:
Installing profiles is not without cost. It has both a performance cost (boot time for loading profiles) and most of all a maintenance cost. Especailly when the user range is "everyone" which includes users without deep understanding of profiles or even system administration, the risk of introducing friction and the need for updates/patches in profiles needs to be minimal. Consequently the number of profiles should be as small as possible. Based on previous discussions there are two approaches here:
A) Install only profiles for applications that are present on the target system, including all services regardless of attack surface.
B) Install only select profiles (and their required dependencies) based on the risk they represent.

As mentioned before, I strongly lean toward B) since it reduces the number of required profiles significantly and I dont see any valid use case for profiles that isolate applications without relevant attack surface. Having a profile for GUI calculator apps does nothing for security, since there is no reasonable threat model that would put this application at risk by parsing untrusted data.

In research the threat to a specific system is measured by attack surface based on software entry points, privileges required, privileged gaind by exploitation and exposure to potential adversaries. Consequently the use of apparmor should follow this approach to address applications with a relevant attack surface first. On servers that would include any server processes exposed to the network. On desktop systems that would be mostly browsers, though its a more complicated question how much that actually does, given that modern browsers have far more advanced process isolation implemented already and if an adversary overcomes that (which usually includes kernel exploits) apparmor may not present a significant challenge anymore that would not be overcome by the same methods.
However most software on Linux does not come with any process isolation, especailly not anything as advanced as what browsers have.
The primary use case for apparmor profiles would be any applications that parse untrusted data. Which would include targets like media players, file processors, image viewers (e.g. vlc player, libreoffice) which also happen to be the primary target for actual real world malware.

By addressing the applications that actually parse untrusted data, either locally or over the network, the primary attack vectors are addressed, which should therefore be the default objective.
There may be some use for having profiles for everything else like tools that can only be run by root, but I honestly do not see what the use case is for real world systems, so I consider this to be more a theoretical approach.

Given the significant maintenance effort that is added by profiles which do not address relevant attack surface but still risk breaking the system, I am strongly arguing towards a default install method that provides profiles only for installed applications that are actually exposed to relevant attack surface. When VLC breaks because an update introduced a change that the profile did not catch in time, that is the minimal risk we have to live with, but breaking a system because the profile for grub is outdated and the user now has an unbooteable seems questionable as I cannot find any benefit for that profile that would address a realistic threat. I dont think many users would have the patience for that either.