Security boundaries

[valoq]

As stated in the project objectives, the profiles in this repository are designed to provide comparable isolation to those present on mobile operating systems.
The problem with this approach as I see it, is that is does not align well with the expectation of (many) Linux users that wish to isolate their applications through apparmor. Not only does Linux not provide nearly the same infrastructure and common methods of sharing file like the share feature on Android/IOS, the use cases of most Linux applications are a lot broader since general purpose systems like most Linux Desktops are quite different from mobile systems. When the mobile approach for security boundaries is applied to apparmor profiles intended for general purpose systems, this leads back to the dreaded "OMG apparmor again" situation that we want to avoid.

Instead of forcing rather alien security boundaries of mobile systems into the apparmor profiles in this repository that are meant for desktop systems, I would suggest a more reasonable approach for normal desktop applications. Instead of trying to bind file access for applications like image viewers to specific directories like "Pictures" and preventing any user from viewing image files in e.g. ~/Downloads or ~/MyWorkProjects by default, read access should be granted to any directory located in places that commonly contain any user files like in this example.
The difference for the practical security the apparmor profiles provide with this approach compared to the more limited mobile approach is nearly non existent for most applications, at least when no network access is required. The main objective should be to prevent any easy sandbox escape, like it would be possible if write access to hidden files are granted. For applications that do not have network access, the number of non hidden directories in $HOME they can read is completely irrelevant to the provided security of the profile.

If an image viewer is compromised there are two possible consequences:

1. The apparmor profile provides enough isolation to prevent sandbox escape and no other system vulnerability like privilege escalation through kernel vulnerabilities are present to be exploited. If this holds true the number of accessible normal user files is irrelevant since they cannot be extracted or manipulated.
2. The apparmor profile allows sandbox escape or another system vulnerabilities allows the circumvention of apparmor. In this case the number of accessible normal user files is still irrelevant since all of apparmors isolation can be circumvented.

In consequence, requiring a strict isolation of normal user files (as in pictures, documents, music ...) only makes using the apparmor profiles harder while it provides no security benefits as long as the profile is already isolated to the local system, meaning no known sandbox escape or path for extracting files like network access. (I would also consider the absence of X11 access a requirement)

For applications that require network access, the current approach makes a lot more sense and when a browser only gets access to ~/Downloads this is a lot more reasonable compared to restricting an image viewer to ~/Pictures despite the lack of network access.

Consequently I suggest to change the defined isolation objective for profiles to include a more granular decision tree in regard to how much access to files can be permitted.

[roddhjav]

I had a bit of thought about it. And it is still a hard no. However...

A complete reply should be me pushing a security model for this project (but that is still a wip). For now, I will keep it short (and incomplete).

The main idea behind MAC, is not to target some specific attacks and to protect the application against them. But to protect the application confined against unknown attack, ie: anything (within the limit of apparmor capabilities, obviously apparmor is neither a firewall nor a sandbox manager). In other words, the best (and only) way to ensure protection against an unknown range of attack is to use and abuse the principle of least privilege. It is exactly what this project is doing. Consequently, a profile should respect the same general rule regardless of its allowed access (internet, IPC, caps...).

Regarding usability, Linux applications do not have security as compatibility requirement. Therefore, yes, trying to enforce any sort of security will always generate some compatibility issue. However, it does not mean that we do not have standards. The first being the XDG style directory definition. It is the option I selected in this project: you are free to organize yourself as you want... as long as you define your directories in apparmor. Is it a trade of regarding usability vs security? Yes. However, I am convinced it is the only way for Linux system to provide state-of-the-art security.

This is for the theory. Regarding this specific example, we are talking about user data. To the end user, these are much more sensitive than anything else on the system. So being extra careful with them and not allowing owner @{HOME}/[^.]** makes sense. Otherwise, the risk of such a construction is an issue that Android also has: xkcd 1319:

Instead of trying to bind file access for applications like image viewers to specific directories like "Pictures" and preventing any user from viewing image files in e.g. ~/Downloads or ~/MyWorkProjects by default, read access should be granted to any directory located in places that commonly contain any user files like in this example.

It works this way already for most profiles. For example, loupe has full access over all labelled directories. While vlc allow a smaller list of these directories. Is it perfect? Probably no, but it is both fully user configurable and much more restrictive than a systematic @{HOME}/[^.]**.

The only difference is that the current user-read abstraction ensures directories are well-defined under label (variable) such as we can easily update/control them now and in the future.

As stated in the project objectives, the profiles in this repository are designed to provide comparable isolation to those present on mobile operating systems.

Nitpicking, but I have never said this. I take inspiration from the Android security implementation that features (among other things) full system confinement. It does not mean this project's aim is to implement all Android features... The reading of their security model can be a reminder that Google is first and foremost an ads company.

However

Despite this theory, I acknowledge that it might be a pain to have to handle extra configuration. Even more as it is still an early stage of the project. Therefore, I am also for a pragmatic implementation:

• Ideally, all user directories should be correctly labelled so that we can easily control them.
• But a leaser restriction is still far better than nothing.

In conclusion

• I have rewritten the user abstractions (see 2fc2394). There is user-read and user-write (they have @{HOME}/[^.]**). While user-read-strict, user-write-strict only allow directories covered by variables.
• If you create a PR for a profile that use user-read or user-write, I will most likely said no.
• You are very welcome to propose new user style variables for user directory not yet covered.

Extra note

This may be revisited later, especially as a future version of apparmor will add a prompt keyword that will allow us to ask confirmation from the user before access is given.

[beroal]

I did not know about prompt. While it is close to what I want, it requires double work. First, I open a file $F in a program; then I check that the opened file is $F. Why not choose $F one time in a system dialog?

[roddhjav]

Not sure I understand your question here. But the profile is trusted while the user is not really trusted. Therefore, apparmor will only ask confirmation to the user when the profile tell apparmor it can do it for some rule (ie: a restricted set of rules under prompt`)

[beroal]

My remark is about optimizing the UI. Say, the profile for a graphics editor contains the rule prompt @{HOME}/{,**} rw. A user still needs to specify a file $F in $HOME to edit. So the user does this by opening $F in the graphics editor.

BTW, I can't find anything about this “prompt” feature on the web. Do you have any additional info?

[roddhjav]

It is an upcoming feature (the kernel side of apparmor need to support it). The integration into apparmor.d will depends on how exactly the feature work.

[valoq]

It works this way already for most profiles. For example, loupe has full access over all labelled directories. While vlc allow a smaller list of these directories. Is it perfect? Probably no, but it is both fully user configurable and much more restrictive than a systematic @{HOME}/[^.]**.

My suggestion would address this inconsistency and instead apply a rule to which restriction can/should be set by default when conditions are met.
To quote the xkcd: "to read my email, take my money, and impersonate me" is not possible in the proposed scenario, as access to arbitrary user files is only granted when no network/extraction path is available.
For some reason the example profiles you pointed out already implement this as it seems that vlc (which is restricted to specific XDG directories) has network access while the less restricted loupe does not have any permissions that would allow file extraction.

However

Despite this theory, I acknowledge that it might be a pain to have to handle extra configuration. Even more as it is still an early stage of the project. Therefore, I am also for a pragmatic implementation:

* Ideally, all user directories should be correctly labelled so that we can easily control them.

* But a leaser restriction is still far better than nothing.

In conclusion

* I have rewritten the user abstractions (see [2fc2394](https://github.com/roddhjav/apparmor.d/commit/2fc2394bad4f89dc0e367b8bc45c63196e4ef259)). There is `user-read` and  `user-write` (they have `@{HOME}/[^.]**`). While `user-read-strict`, `user-write-strict` only allow directories covered by variables.

This was basically what I intended to provide with #292 to avoid the need for users to redefine this optional abstraction.

* If you create a PR for a profile that use `user-read` or `user-write`, I will most likely said no.

My idea would be to add a simple condition for this abstraction before it is permitted:

• No network access
• No X11 access
• No full device access (or at least no terminal access)

If those conditions are met, there should be little reason not to allow this lesser restriction for the above mentioned reasons.
Not to mention it would also allow more consistent profiles.

[beroal]

I don't agree that all programs without internet access should be allowed to access every user file. Then any program can delete all my work. Instead, I want that a program has access only to files I choose and only for the time period I choose.

Android since the 4th version has been moving to this security policy. However, AppArmor does not have such a feature. Probably, because it was designed for a different use case.

BTW, surprisingly large number of application programs require internet access. For example, mpv can play URLs. IMHO, in this case, internet access should be given dynamically as I described above for file access.

[valoq]

I don't agree that all programs without internet access should be allowed to access every user file. Then any program can delete all my work.

The condition includes only read access, so it should not matter at all since no damage can be done (as long as apparmor holds)

Instead, I want that a program has access only to files I choose and only for the time period I choose.

The problem is what to choose as a default, because the files you want a program to access are almost always different from the next users files.

Perhaps a solution may be to define different access levels for user files and allow automatically setting the desired permissions at install time. For example:

Option A)
Allow access to extended XDG directories (like it is currently the case for many profiles)

Option B)
Allow access to all user files in $HOME and $MOUNTPOINTS (excluding hidden files)

Option C)
Set custom access permissions

This could be combined with a definition of application classes like Document-Applications, Media-Applications, Internet-Applications

[curiosityseeker]

I sympathize with this idea. I suggest the following approach:

1. Allow read access according to the user-read abstraction.
2. Deny access to critical files/folders by adding the deny-sensitive-home and private-files-strict abstractions.
3. Limit write access to the supported file formats - similarly like Ubuntu is doing it in their libreoffice profile:

#Defines all common supported file formats
#Some obscure ones we're excluded (mostly input)

#Generic
#.txt
@{libreoffice_ext} = [tT][xX][tT]
#All the open document format
@{libreoffice_ext} += {,f,F}[oO][dDtT][tTsSpPbBgGfF]
#.xml and xsl
@{libreoffice_ext} += [xX][mMsS][lL]
#.pdf
@{libreoffice_ext} += [pP][dD][fF]
#Unified office format
@{libreoffice_ext} += [uU][oO][fFtTsSpP]
#(x)htm(l)
@{libreoffice_ext} += {,x,X}[hH][tT][mM]{,l,L}
#.epub
@{libreoffice_ext} += [eE][pP][uU][bB]
#.ps (printing to file)
@{libreoffice_ext} += [pP][sS]

#Images
@{libreoffice_ext} += [jJ][pP][gG]
@{libreoffice_ext} += [jJ][pP][eE][gG]
@{libreoffice_ext} += [pP][nN][gG]
@{libreoffice_ext} += [sS][vV][gG]
@{libreoffice_ext} += [sS][vV][gG][zZ]
@{libreoffice_ext} += [tT][iI][fF]
@{libreoffice_ext} += [tT][iI][fF][fF]

#Writer
@{libreoffice_ext} += [dD][oO][cCtT]{,x,X}
@{libreoffice_ext} += [rR][tT][fF]

#Calc
@{libreoffice_ext} += [xX][lL][sStT]{,x,X,m,M}
@{libreoffice_ext} += [xX][lL][wW]
#.dif dbf
@{libreoffice_ext} += [dD][iIbB][fF]
#.tsv .csv
@{libreoffice_ext} += [cCtT][sS][vV]
@{libreoffice_ext} += [sS][lL][kK]

#Impress/Draw
@{libreoffice_ext} += [pP][pP][tTsS]{,x,X}
@{libreoffice_ext} += [pP][oO][tT]{,m,M}
#Photoshop
@{libreoffice_ext} += [pP][sS][dD]

#Math
@{libreoffice_ext} += [mM][mM][lL]

....

owner @{HOME}/**.@{libreoffice_ext} rwk,
owner @{MOUNTS}/**.@{libreoffice_ext} rwk,

This can also be implemented in a similar way for e.g., okular, evince, gwenview etc.

[valoq]

I sympathize with this idea. I suggest the following approach:

1. Allow read access according to the `user-read` abstraction.

This should depend on the other permissions within the profile. As long as the profile does not allow network access to exfiltrate the data, the amount of normal user data the app may access has no real effect on security.

What I find even more disturbing is the illusion of control the user-read-strict abstraction implies:
Either the user has all their files in the XDG directories that are accessible with user-read-strict, or the apparmor profiles will get in their way e.g. for files like @{HOME}/myproject. So the only ways to deal with this is to either expand the permissions or move the myprojects directory inside one of the predefined XDG directories. If all files are in the XDG directories, this allows access to the very same files that were accessible with the user-read abstraction that allows access to all non hidden files in home.

The point Alex is trying to make with this XDG abstraction does seem valid to me in theory, especially in terms of the idea of moving towards the mobile platform permission model. But the fact remains that Linux desktops are still far away from the infrastructure that enables this mobile platform permission model to become an effective and usable environment. Without things like a "share" button to send a file from one application to another, applications need common access to user files they may potentially have to access and
forcing files into predefined directories will not add anything in terms of security.

2. Deny access to critical files/folders by adding the `deny-sensitive-home` and `private-files-strict` abstractions.

The user-read abstractions already do not allow access to those files. They allow access only to files in @HOME that do not start with a dot.

apparmor.d/apparmor.d/abstractions/user-read

Line 11 in c3de88e

owner @{MOUNTS}/[^.]** r,

Additionally, deny rules should also be avoided at all costs.
See the chapter on Enumerating Badness here: https://www.ranum.com/security/computer_security/editorials/dumb/

3. Limit write access to the supported file formats - similarly like Ubuntu is doing it in their libreoffice profile:

This idea sounds quite promising, assuming it works reliably in apparmor.
@roddhjav Did you consider this approach before? I am curious if there are any hidden issues with filtering file extensions like this.

[curiosityseeker]

The user-read abstractions already do not allow access to those files. They allow access only to files in @HOME that do not start with a dot.

Yes, that's true. My mistake.

3. Limit write access to the supported file formats - similarly like Ubuntu is doing it in their libreoffice profile:

This idea sounds quite promising, assuming it works reliably in apparmor. @roddhjav Did you consider this approach before? I am curious if there are any hidden issues with filtering file extensions like this.

Well, it has obviously worked in Ubuntu for several years. And I've been using this approach as well in some profiles for quite a while. The only problem is that you'll get a lot of noise by denials in aa-log for the non-@{libreoffice_ext} files. I don't know how to avoid this.

EDIT: Your comment about deny rules is certainly correct. Nevertheless, they can limit the risks of (potentially) too loose permisions - and remember, we're talking about read permissions here. Another useful side effect is that deny rules silence logging in aa-logprof or aa-log. Unfortunately, something like deny @{HOME}/[^**.@\{libreoffice_ext\}] rw, does not work, and it also blocks access to, e.g., @{user_config_dirs} and @{user_cache_dirs}.

Hint: If you want to test this you should not add above code for the @{libreoffice_ext} definitions in the .../local/libreoffice file. The apparmor_parser won't accept that for whatever reason. You have to add it to the profile itself.