Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.
From: Crispin Cowan
Date: Thu Apr 17 2008 - 03:47:14 EST
Stephen Smalley wrote:
On Mon, 2008-04-14 at 21:59 -0700, Crispin Cowan wrote:
Stephen Smalley wrote:
On Sun, 2008-04-13 at 19:05 -0700, Crispin Cowan wrote:
Things that pathname-based access control is good at:
* *System Integrity:* Many of the vital components of a UNIX system
are stored in files with Well Known Names such as /etc/shadow,
/var/www/htdocs/index.html and /home/crispin/.ssh/known_hosts. The
contents of the actual data blocks is less important than the
integrity of what some random process gets when it asks for these
resources by name. Preserving the integrity of what responds to
the Well Known Name is thus easier if you restrict access based on
the name.
I think some might argue that the integrity of the data in /etc/shadow
and your .ssh files is very important, not just their names.
I understand how the confidentiality of secrets like the contents of
/etc/shadow and your .ssh files is important, but how can the integrity
of these data objects be important? Back them up if you care ...
If you aren't concerned with unauthorized data flow into
your /etc/shadow and .ssh files, then I think we'll just have to stop
right there in our discussion, as we evidently don't have a common point
of reference in what we mean by "security". Personally I'd be troubled
if an unauthorized entity can ultimately feed data to such files, even
if indirectly by tricking a privileged process into conveying the data
to its ultimate target, a not-so-uncommon pattern.
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"?
And
ultimately data integrity requires information flow control to preserve.
You've argued that before, and I've never been convinced. Rather, it
looked a lot like a stretched definition trying really hard to turn
integrity into an information flow problem.The most information flow
that I will buy in the integrity problem is taint analysis of software
inputs; that software should validate inputs before acting on it.
In some cases, you can simply prohibit a security-relevant process from
taking untrustworthy inputs. Like blocking privileged processes from
following untrustworthy symlinks to counter malicious symlink attacks or
from reading any files other than ones created by the admin. In other
cases, you need to allow untrustworthy inputs to ultimately flow to the
security-relevant process, but you want to force them through some kind
of validation as you say above, which you can do by enforcing a
processing pipeline that forces the data to go through a subsystem that
performs validation and/or sanitization before it ever reaches the
security-relevant process. That's how integrity is an information flow
problem. And this isn't a new idea, btw, it is one that was expressed
long ago in the Biba model, a variant of which happens to be implemented
and used in Vista, and is more usefully achievable via Type Enforcement
since there we can control the processing flow precisely and bind the
validation/sanitization subsystem to specific code.
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.
- anything further is misleading as the
server or device won't ensure any finer grained separation for us.
I don't understand this issue. The enforcement here is t contain the
program executing on the NFS *client* to permit it to only mangle the
parts of the NFS mount that you want it to mangle. That the server won't
enforce anything for you is irrelevant when the threat is the confined
application.
Except that you have to consider what is happening on the server too,
given that the files are visible to local processes there, and what
happens on all of the clients.
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.
It isn't a strawman argument. I know that AppArmor doesn't try to apply
pathnames to non-files. Which leads it down the first case of
inconsistent" control - at the end of the day in looking at an AppArmor
policy you can't say anything about how information may have ultimately
flowed in violation of your confidentiality or integrity goals because
you have a lossy abstraction. Whereas we can convey the same uniform
control over files, network IPC, local IPC, etc and make such
statements.
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.
- forcing policy to be written in terms of individual objects and
filesystem layout rather than security properties.
Note also that the SELinux restorecon mechanism also makes the
assumption that path names correspond to security properties: in fact,
that is precisely its function, to take a path name and use it to apply
a security property (a label). Naturally I have no objection to
inferring a security property from the path name :) I just object to the
racy way that restorecon does it, combined with the complaint that
AppArmor is wrong for doing exactly the same thing in a different way.
Making that inference when a file is first installed (as from rpm) is
reasonable. restorecon (the utility) is for the filesystem to the
initial install-time labeling state, which is why it uses the same
mapping. Making that inference on every access in complete ignorance of
the actual runtime state of the system is what I object to.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/