14 Apr, 2009

1 commit

  • the following patch, add logging of Smack security decisions.
    This is of course very useful to understand what your current smack policy does.
    As suggested by Casey, it also now forbids labels with ', " or \

    It introduces a '/smack/logging' switch :
    0: no logging
    1: log denied (default)
    2: log accepted
    3: log denied&accepted

    Signed-off-by: Etienne Basset
    Acked-by: Casey Schaufler
    Acked-by: Eric Paris
    Signed-off-by: James Morris

    Etienne Basset
     

28 Mar, 2009

1 commit

  • This patch adds a new special option '-CIPSO' to the Smack subsystem. When used
    in the netlabel list, it means "use CIPSO networking". A use case is when your
    local network speaks CIPSO and you want also to connect to the unlabeled
    Internet. This patch also add some documentation describing that. The patch
    also corrects an oops when setting a '' SMACK64 xattr to a file.

    Signed-off-by: Etienne Basset
    Signed-off-by: Paul Moore
    Acked-by: Casey Schaufler
    Signed-off-by: James Morris

    Etienne Basset
     

06 Feb, 2008

1 commit

  • 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: Casey Schaufler
    Cc: Joshua Brindle
    Cc: Paul Moore
    Cc: Stephen Smalley
    Cc: Chris Wright
    Cc: James Morris
    Cc: "Ahmed S. Darwish"
    Cc: Andrew G. Morgan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Casey Schaufler