Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, ...)

Question

I have been learning about MAC (Mandatory Access Control) systems in Linux. Often, but not always, these are tied to Linux Security Modules. Some systems I've looked at: SELinux, Tomoyo, AppArmor, grsecurity, Smack.

As far as I understood, all those systems rely on setting up a catalog of rules. Those rules define finer-grained access policies for files and system resources and thus provide increased security.

Given the intent to restrict access to file, it is logical that we have to know "which" files and hence file references are essential for those rules to make sense. This is what my question is related to.

With the noticable exception of SELinux and Smack, the other approaches use file paths (pathnames) to identify the files in the rules. I have seen others judge this approach insecure, because one file could have several names at the same time (links, bind-mounting, etc).

Is the approach of using pathnames secure? What are the advantages and disadvantages of these pathname-based schemes? Would it be accurate to state that "Pathname-based MAC (such as TOMOYO, grsecurity, AppArmor, …) have a real conceptual flaw"?

Answer 1

Quite frequently this appraoch is judged insecure stating that one file could have several names at the same time (links, bind-mounting etc).

It is most certainly true that one file could have multiple security contexts, one for each name. However, whether or not this is insecure depends on how you view it:

• This feature of AppArmor does not require that remote filesystems support AppArmor, so for example it can be implemented for NFS paths.
• Usually, Unix DAC remains enabled, so even interesting applications such as the contents of /usr/bin should not be writeable. In theory!
• There may be additional controls to prevent end users from mounting or symlinking.

However, all of that aside, the goal of MAC-type projects is to confine processes as well as users, so that a process run as user only runs with the necessary permissions it needs. Few applications, except perhaps ln, need the ability to create symbolic links and those that do do not require them on all directories and paths. So it should be possible to implement the desired containment for most processes.

Whilst not suffering from the potential issue in pathnames, inode-based security does have its problems:

• The information attached to file security is stored in xattrs (extended attributes) which means special considerations for network file systems.
• Some applications change inode values which can cause issues working with security contexts - specifically your file is likely to revert to the default security context if you edit it and vim operates this way.

I think the difference is quite subtle and it is not a case of one is more secure than the other, as that each has its advantages and drawbacks. Properly understood, both enable secure policies to be implemented.

Answer 2

Grsecurity is not a pure pathname-based MAC system like TOMOYO or AppArmor. Policy is described using pathnames (same as every other system, including SELinux), but these are converted to inode/dev pairs at enable time and used thereafter. Pathnames are only used when matching regular expressions from policy or to provide "policy-recreation" -- given the case in the other comment here of SELinux reverting a file modified by vim to the default security context (a serious issue!), grsecurity will detect this case and apply the previous policy on that object to the new one.

Funnily, while lumping in grsecurity with pure pathname-based MAC systems and spreading FUD, SELinux itself has recently added use of filename information in recent versions to do exactly what grsecurity has been doing since day 1.

It seems true what Schopenhauer said: "All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident."

I discuss more details on this topic in my grsecurity RBAC tutorial presentation: https://grsecurity.net/rbac_tutorial.pdf

-Brad

Answer 3

I think, pathname based access control in general is not flawed conceptually at all, it may even have advantages, but current implementations are not convenient.

Advantage is that you can have cleaner and more understandable policy specified in the single place, and you don't have complications of xattrs spreading over whole filesystem. Thinkability, I say, which is important. Disadvantage is that some implementations are not able to handle hardlinking or rename in easy for users way.

There are answers from TOMOYO authors: http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#g6a56098 Basically, they say that you can forbid linking/rename of important files, and that by default linking/renaming is forbidden, so "no problems". I disagree, all that complicates policy creation and maintaining. Well, it depends on what goals you have, though.