Of *course* AppArmor protects the integrity of /etc/shadow, and
unauthorized parties are not permitted to feed data into that file
unless explicit access is granted. The difference is in how it is done:
* SELinux marks the inode with a label, and only processes with the
right permissions can mess with the label.
o Residual problem: someone could rename the inode and drop a
new inode into place named "/etc/shadow". SELinux addresses
this with access control on the parent directory.
* AppArmor checks the name "/etc/shadow" so that you cannot access
that name without explicit permission.
o AppArmor cares about the integrity of what the OS returns
when you access the name "/etc/shadow" and does not care a
wit what happens to the inode that was *previously* named
"/etc/shadow".
Now, without running off into the weeds again, tell me again why I
should care about the *integrity* of an inode that was *previously*
known as "/etc/shadow"?
Ok. I view the above as a marginal nice-to-have property that I don't
actually care much about, because it is a large amount of work to manage
for a small amount of integrity to gain. People who want that should use
some kind of information flow controlling policy system like SELinux.
IMHO people with that need are a small minority, which is why I think it
is over-strong to say that integrity "requires" information flow
control. No it doesn't; the particular form of integrity you are talking
about requires information flow control, but other forms do not.
You don't have to consider any such thing when you are *only* concerned
with confining the impact of the process running on the NFS client.
If you want to concern yourself with funny business coming from other
clients, then you need to apply policy to those other clients. If you
want to control funny business happening on the server, then you need to
apply security policy to the server. But this is all irrelevant to
secure confinement of the single NFS client process being confined.
Conversely, at the end of the day you can't say much about what your
SELinux policy enforces, because you can't understand it :)
Duality again: SELinux policy is easier for machines (semantic
analyzers) to understand. AppArmor is easier for humans to understand.
So associating a security property with a name is ok if you do it
statically at some arbitrary point in time, but not if you consider it
at the time of access? WtF? Isn't that a gigantic race condition?
To the contrary, I argue that the *current* name of a file is vastly
more meaningful for security properties than the name the file had some
months ago when someone ran restorecon over the file system.
I've said this before too: SELinux works well if your IT systems are
static. AppArmor works better if your IT systems change, precisely
because it evaluates the access based on the name at the time of access,
rather than some historic name the file once had.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
The Olympic Games: Symbolizing oppressiiion and corruption for over a
hundred years
--
