Re: c2 (or c2-like) auditing for Linux

sdsat_private

Casey wrote:
> LSM is a Good Thing (tm) because it is explicitly present, and
> everyone has to deal with that, and not screw it up.

You might have missed it, but LSM is now a configuration option, turned
off by default.  Kernel developers are quite free to ignore it,
although that is obviously not what we would prefer.  Even before a
config option was created for it, there were a few instances where
hooks that were merged into earlier versions of 2.5 were silently
dropped by other functional changes to the base code and we've had to
submit patches restoring those hooks.

> Since C2 (CAPP in CC speak) doesn't include MAC let's
> assume B1 (LSPP). Error checks (e.g. EBADF, EINVAL) should
> be done first, and as suggested do not require audit records
> as no access control checks are done. The order of
> MAC vs. DAC checks is pretty well fixed by the MAC policy,
> in that unlike the DAC policy if you don't have MAC access
> to a file you shouldn't be able to see it's attributes
> (i.e. stat(2) should fail) so you should never be able to
> see the DAC attributes to make the DAC check in a case where
> you lack MAC access.

The process doesn't see the DAC attributes, the kernel does, and the
process can't infer information about the DAC attributes if the error
codes for DAC failure and MAC failure are the same.  Also, note that
some error checks that precede permission checks can convey information
about the file and do return other error codes (e.g. ENOTDIR, EISDIR,
ENOTEMPTY).  Hence, your above statement about error checking always
occurring first isn't consistent with your stated goal for MAC.

> True, the kernel code does have access,
> and in fact you need to report the DAC information in the audit
> record. You could do the DAC check first, and might still be
> compliant, but a MAC failure is much more interesting than
> a DAC failure, so you're going to have an uphill battle
> convincing an evaluation team (or a serious user, for that
> matter) that you've made the right choice just because the
> code's a little easier to get past the community.

Unclassified process trying to read top secret data is certainly more
interesting than Steve trying to read Casey's data (well, maybe Casey's
data is more interesting...).  But there is also plenty of noise
generated by harmless probing/access testing that occurs as part of
normal operation of existing applications.

In any event, if the DAC logic is moved into the security module, this
all becomes a module issue and preferably a policy configuration issue.
You can then combine your DAC and MAC access control logic and auditing
however you wish.  

--
Stephen Smalley, NSA
sdsat_private

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module