• Casey Schaufler's avatar
    Smack: Simplified Mandatory Access Control Kernel · e114e473
    Casey Schaufler authored
    Smack is the Simplified Mandatory Access Control Kernel.
    
    Smack implements mandatory access control (MAC) using labels
    attached to tasks and data containers, including files, SVIPC,
    and other tasks. Smack is a kernel based scheme that requires
    an absolute minimum of application support and a very small
    amount of configuration data.
    
    Smack uses extended attributes and
    provides a set of general mount options, borrowing technics used
    elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides
    a pseudo-filesystem smackfs that is used for manipulation of
    system Smack attributes.
    
    The patch, patches for ls and sshd, a README, a startup script,
    and x86 binaries for ls and sshd are also available on
    
        http://www.schaufler-ca.com
    
    Development has been done using Fedora Core 7 in a virtual machine
    environment and on an old Sony laptop.
    
    Smack provides mandatory access controls based on the label attached
    to a task and the label attached to the object it is attempting to
    access. Smack labels are deliberately short (1-23 characters) text
    strings. Single character labels using special characters are reserved
    for system use. The only operation applied to Smack labels is equality
    comparison. No wildcards or expressions, regular or otherwise, are
    used. Smack labels are composed of printable characters and may not
    include "/".
    
    A file always gets the Smack label of the task that created it.
    
    Smack defines and uses these labels:
    
        "*" - pronounced "star"
        "_" - pronounced "floor"
        "^" - pronounced "hat"
        "?" - pronounced "huh"
    
    The access rules enforced by Smack are, in order:
    
    1. Any access requested by a task labeled "*" is denied.
    2. A read or execute access requested by a task labeled "^"
       is permitted.
    3. A read or execute access requested on an object labeled "_"
       is permitted.
    4. Any access requested on an object labeled "*" is permitted.
    5. Any access requested by a task on an object with the same
       label is permitted.
    6. Any access requested that is explicitly defined in the loaded
       rule set is permitted.
    7. Any other access is denied.
    
    Rules may be explicitly defined by writing subject,object,access
    triples to /smack/load.
    
    Smack rule sets can be easily defined that describe Bell&LaPadula
    sensitivity, Biba integrity, and a variety of interesting
    configurations. Smack rule sets can be modified on the fly to
    accommodate changes in the operating environment or even the time
    of day.
    
    Some practical use cases:
    
    Hierarchical levels. The less common of the two usual uses
    for MLS systems is to define hierarchical levels, often
    unclassified, confidential, secret, and so on. To set up smack
    to support this, these rules could be defined:
    
       C        Unclass rx
       S        C       rx
       S        Unclass rx
       TS       S       rx
       TS       C       rx
       TS       Unclass rx
    
    A TS process can read S, C, and Unclass data, but cannot write it.
    An S process can read C and Unclass. Note that specifying that
    TS can read S and S can read C does not imply TS can read C, it
    has to be explicitly stated.
    
    Non-hierarchical categories. This is the more common of the
    usual uses for an MLS system. Since the default rule is that a
    subject cannot access an object with a different label no
    access rules are required to implement compartmentalization.
    
    A case that the Bell & LaPadula policy does not allow is demonstrated
    with this Smack access rule:
    
    A case that Bell&LaPadula does not allow that Smack does:
    
        ESPN    ABC   r
        ABC     ESPN  r
    
    On my portable video device I have two applications, one that
    shows ABC programming and the other ESPN programming. ESPN wants
    to show me sport stories that show up as news, and ABC will
    only provide minimal information about a sports story if ESPN
    is covering it. Each side can look at the other's info, neither
    can change the other. Neither can see what FOX is up to, which
    is just as well all things considered.
    
    Another case that I especially like:
    
        SatData Guard   w
        Guard   Publish w
    
    A program running with the Guard label opens a UDP socket and
    accepts messages sent by a program running with a SatData label.
    The Guard program inspects the message to ensure it is wholesome
    and if it is sends it to a program running with the Publish label.
    This program then puts the information passed in an appropriate
    place. Note that the Guard program cannot write to a Publish
    file system object because file system semanitic require read as
    well as write.
    
    The four cases (categories, levels, mutual read, guardbox) here
    are all quite real, and problems I've been asked to solve over
    the years. The first two are easy to do with traditonal MLS systems
    while the last two you can't without invoking privilege, at least
    for a while.
    Signed-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
    Cc: Joshua Brindle <method@manicmethod.com>
    Cc: Paul Moore <paul.moore@hp.com>
    Cc: Stephen Smalley <sds@tycho.nsa.gov>
    Cc: Chris Wright <chrisw@sous-sol.org>
    Cc: James Morris <jmorris@namei.org>
    Cc: "Ahmed S. Darwish" <darwish.07@gmail.com>
    Cc: Andrew G. Morgan <morgan@kernel.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    e114e473
Makefile 123 Bytes