Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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"?

share|improve this question

3 Answers 3

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.

share|improve this answer
    
I enjoyed reading of the problems you mentioned about inode-based MAC (which as I think is SELinux only...afterall not to much variety in security systems :(). The other parts have been quite enlightening also, thank you –  humanityANDpeace Dec 18 '12 at 14:03

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

share|improve this answer
1  
Wow. If indeed true, I am humbled to receive an answer from one of the authors of a MAC here. Thank you for the time. Secondly I would like to clarify that at no point I wanted to put grsecurity (neither any other) of the works into a "common bunch". Indeed I am quite certain I could hardly now enough at present to be able to group or order the solutions. 3) I enjoyed the informaiton regarding the change of SELinux that might have escaped me as I though most would be inode and indeed xattr based lableling. 4) all this of course makes me have a closer look to grsecurity :) THANK's Brad –  humanityANDpeace Dec 18 '12 at 14:09
    
Ingenious the "convert pathname to inode" at rule-set-time solution. Sorry but this seems just such a smart idea to escape the troubles some LSM developers have said to have when seeing that LSM hooks would have not enough and not always the pathname info. –  humanityANDpeace Dec 18 '12 at 14:11

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.

share|improve this answer
    
thank you for the link to the TOMOYO's people responding to certain doubts about the pathname approach –  humanityANDpeace Dec 27 '12 at 14:16
    
@humanityANDpeace: Additional paper from TOMOYO author sourceforge.jp/projects/tomoyo/docs/lfj2008-bof.pdf about the role of "pathname based access control" in security. And this sourceforge.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf with more discussions on it. –  catpnosis Jan 1 '13 at 12:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.