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

From: Stephen D. Smalley (sdsat_private)
Date: Thu Jan 30 2003 - 10:36:37 PST

  • Next message: Casey Schaufler: "Re: c2 (or c2-like) auditing for Linux"

    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
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu Jan 30 2003 - 10:30:30 PST