Eloquently put.
AppArmor actually does something similar to this, by mediating all of
the ways that you can make an alias to a file. These are:
* Symbolic links: these actually don't work for making aliases with
respect to LSM-based security systems such as AppArmor, SELinux,
and TOMOYO Linux, because the symbolic link is resolved before the
access request is presented to the LSM hooks. So if you create the
symbolic link /tmp/harmless -> /etc/shadow and then the confined
victim tries to access /tmp/harmless, what the LSM sees is an
attempt to access /etc/shadow.
* Hard links: AppArmor explicitly mediates permission to make a hard
link to a file. To be able to make a hard link /tmp/harmless ->
/etc/shadow you have to have explicit permission to do so, or the
attempt to make the link is blocked. This mediation is kept
relatively simple by the fact that you can only hard link to
files, and not to directories.
* Multiple mounts: Linux lets you mount the same file system
multiple times at multiple mount points, so the same file could
appear at two different places. AppArmor has very coarse mediation
here, and simply prohibits all calls to mount() without special
permission. So only highly privileged processes can create such an
alias.
* Name spaces: Linux name spaces present a similar issue, and
AppArmor's coarse blocking of mount() serves the same function;
only highly privileged processes are permitted to create name spaces.
We are thinking about something kind of like this for finer-grained
mediation of mount(). Currently it is all-or-nothing; we either totally
block the ability to create aliases with multiple mount points or name
spaces, or we totally trust the process with permission to do what it
likes with multiple mount point and name space aliases.
What we want is a more nuanced mediation of mount point and name space
manipulation, so that you can write a spec that says "/tmp/* can be
aliased any way you like, but /etc/shadow cannot be aliased at all" or
something like that.
However, not much work has been done on this, because at the moment the
AppArmor team is concentrating on making the code for current
functionality acceptable for upstreaming.
This is equivalent to the question of what kind of access to grant to
the data. I don't see it as really difficult. What is harder is that the
specification has to specify what you can alias, and where it can
appear, and dealing with the two factors tends to make one's head hurt.
I am reminded of the pithy quote "Noalias must go. This is not
negotiable" -- Dennis Ritchie, referring to a proposed 'noalias' type
qualifier in ANSI C http://www.lysator.liu.se/c/dmr-on-noalias.html
Mediating permission to make aliases is complicated :(
.. if you use the approach of labeling the files :) In fact this
problem is general: label-based security has a hard time dealing with
new files in general, not just with respect to permission to create
aliases. The security policy for a newly created file is determined by
the label on the file, and so labeling new files is critical. SELinux
uses a variety of smart heuristics to decide the label of a new file:
* the label of the parent directory
* the label of the creating process
* the domain for the creating process can do conditional things
based on the label of the parent directory and the creating process
* applications that link to libselinux can overtly set the label
according to application logic
AppArmor, not using labels, doesn't have this problem. You can write an
AA profile with respect to files and directories that don't exist at all.
As I explained above, a lot of it is already in place with our mediation
of hard links. Our mediation of multiple mount points and name spaces is
lame, but the extent to which this needs to be improved will largely be
determined by how application developers choose to use these features.
Because AppArmor is intended primarily to confine applications, an
administrative approach of just using unconfined (completely trusted)
shells to manipulate name spaces and multiple mount points suffices, and
application manipulation of name spaces and multiple mount points is the
only concern.
That is the information flow problem. While important, it is fairly
separate from the alias problem. The information flow problem is general
to all access control systems, while the alias problem is special to
name-based access control systems.
This is one of the name/label trade-offs. Aliasing is problematic in
name based systems, while new file creation is problematic in label
based systems. This follows directly from the semantics each system is
using:
* Names are references. Name based systems are really mediating
access to references. Thus creating new references and who can
access these new references is problematic.
* Labels are equivalence classes of objects. Label based systems are
really mediating access to objects, regardless of the reference.
Thus creating new objects and who can access these new objects is
problematic.
This depends on where you place the "may alias" access control. You can
put it on the source (/tmp/harmless -> somewhere) on the target
(somewhere -> /etc/shadow) or somewhere else (what AppArmor does,
associating the policy with confined processes).
It could be done, but that has implications. That would mean that you
get the "belt and suspenders" effect of all of the security benefits of
(say) AppArmor and SELinux. But the non-overlapping security benefits
are relatively small (SELinux advocates may dispute this, but whatever,
it is some magnitude). On the other hand, you would get the management
problems of both AppArmor and SELinux; you would have to solve both the
new file problem, and the file alias problem. Think about what you would
have to do to accommodate (say) a text editor's file save procedure of
"write new file.tmp, rename oldfile to oldfile.old, rename newfile.tmp
to oldfile, delete oldfile.old".
So it could be done, but AFAICT, with small benefit and large cost. More
security may be more secure, but it isn't necessarily better.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
Security: It's not linear
-
