30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

10 Jul, 2009

2 commits


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
     

26 Mar, 2009

1 commit


19 Feb, 2009

1 commit


01 Jan, 2009

1 commit

  • Add support for unlabeled network hosts and networks.
    Relies heavily on Paul Moore's netlabel support.

    Creates a new entry in /smack called netlabel. Writes to /smack/netlabel
    take the form:

    A.B.C.D LABEL
    or
    A.B.C.D/N LABEL

    where A.B.C.D is a network address, N is an integer between 0-32,
    and LABEL is the Smack label to be used. If /N is omitted /32 is
    assumed. N designates the netmask for the address. Entries are
    matched by the most specific address/mask pair. 0.0.0.0/0 will
    match everything, while 192.168.1.117/32 will match exactly one
    host.

    A new system label "@", pronounced "web", is defined. Processes
    can not be assigned the web label. An address assigned the web
    label can be written to by any process, and packets coming from
    a web address can be written to any socket. Use of the web label
    is a violation of any strict MAC policy, but the web label has
    been requested many times.

    The nltype entry has been removed from /smack. It did not work right
    and the netlabel interface can be used to specify that all hosts
    be treated as unlabeled.

    CIPSO labels on incoming packets will be honored, even from designated
    single label hosts. Single label hosts can only be written to by
    processes with labels that can write to the label of the host.
    Packets sent to single label hosts will always be unlabeled.

    Once added a single label designation cannot be removed, however
    the label may be changed.

    The behavior of the ambient label remains unchanged.

    Signed-off-by: Casey Schaufler
    Signed-off-by: Paul Moore

    Casey Schaufler
     

14 Nov, 2008

2 commits

  • Wrap current->cred and a few other accessors to hide their actual
    implementation.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Separate the task security context from task_struct. At this point, the
    security data is temporarily embedded in the task_struct with two pointers
    pointing to it.

    Note that the Alpha arch is altered as it refers to (E)UID and (E)GID in
    entry.S via asm-offsets.

    With comment fixes Signed-off-by: Marc Dionne

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     

05 Aug, 2008

1 commit

  • There have been a number of requests to make the Smack LSM
    enforce MAC even in the face of privilege, either capability
    based or superuser based. This is not universally desired,
    however, so it seems desirable to make it optional. Further,
    at least one legacy OS implemented a scheme whereby only
    processes running with one particular label could be exempt
    from MAC. This patch supports these three cases.

    If /smack/onlycap is empty (unset or null-string) privilege
    is enforced in the normal way.

    If /smack/onlycap contains a label only processes running with
    that label may be MAC exempt.

    If the label in /smack/onlycap is the star label ("*") the
    semantics of the star label combine with the privilege
    restrictions to prevent any violations of MAC, even in the
    presence of privilege.

    Again, this will be independent of the privilege scheme.

    Signed-off-by: Casey Schaufler
    Reviewed-by: James Morris

    Casey Schaufler
     

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