On Mon, 2008-04-14 at 21:59 -0700, Crispin Cowan wrote:
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.
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.
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. And the aliasing problem that exists in
the local filesystem case becomes exacerbated in the NFS environment.
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.
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.
--
Stephen Smalley
National Security Agency
--
