[PULL} Smack: changes for linux 3.5

[Casey Schaufler <casey@xxxxxxxxxxxxxxxx>]

Please pull the following changes for the Linux 3.5 merge window.
These changes are available in the git repository:

  http://git.gitorious.org/smack-next/kernel.git for-1205

commit 2267b13a7cad1f9dfe0073c1f902d45953f9faff
Author: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
Date:   Tue Mar 13 19:14:19 2012 -0700

    Smack: recursive tramsmute

    The transmuting directory feature of Smack requires that
    the transmuting attribute be explicitly set in all cases.
    It seems the users of this facility would expect that the
    transmuting attribute be inherited by subdirectories that
    are created in a transmuting directory. This does not seem
    to add any additional complexity to the understanding of
    how the system works.

    Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>

commit ceffec5541cc22486d3ff492e3d76a33a68fbfa3
Author: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
Date:   Thu Mar 29 16:19:05 2012 +0900

    gfp flags for security_inode_alloc()?

    Dave Chinner wrote:
    > Yes, because you have no idea what the calling context is except
    > for the fact that is from somewhere inside filesystem code and the
    > filesystem could be holding locks. Therefore, GFP_NOFS is really the
    > only really safe way to allocate memory here.

    I see. Thank you.

    I'm not sure, but can call trace happen where somewhere inside network
    filesystem or stackable filesystem code with locks held invokes operations that
    involves GFP_KENREL memory allocation outside that filesystem?
    ----------
    [PATCH] SMACK: Fix incorrect GFP_KERNEL usage.

    new_inode_smack() which can be called from smack_inode_alloc_security() needs
    to use GFP_NOFS like SELinux's inode_alloc_security() does, for
    security_inode_alloc() is called from inode_init_always() and
    inode_init_always() is called from xfs_inode_alloc() which is using GFP_NOFS.

    smack_inode_init_security() needs to use GFP_NOFS like
    selinux_inode_init_security() does, for initxattrs() callback function (e.g.
    btrfs_initxattrs()) which is called from security_inode_init_security() is
    using GFP_NOFS.

    smack_audit_rule_match() needs to use GFP_ATOMIC, for
    security_audit_rule_match() can be called from audit_filter_user_rules() and
    audit_filter_user_rules() is called from audit_filter_user() with RCU read lock
    held.

    Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Casey Schaufler <cschaufler@cschaufler-intel.(none)>

commit f7112e6c9abf1c70f001dcf097c1d6e218a93f5c
Author: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
Date:   Sun May 6 15:22:02 2012 -0700

    Smack: allow for significantly longer Smack labels v4

    V4 updated to current linux-security#next
    Targeted for git://gitorious.org/smack-next/kernel.git

    Modern application runtime environments like to use
    naming schemes that are structured and generated without
    human intervention. Even though the Smack limit of 23
    characters for a label name is perfectly rational for
    human use there have been complaints that the limit is
    a problem in environments where names are composed from
    a set or sources, including vendor, author, distribution
    channel and application name. Names like

        softwarehouse-pgwodehouse-coolappstore-mellowmuskrats

    are becoming harder to avoid. This patch introduces long
    label support in Smack. Labels are now limited to 255
    characters instead of the old 23.

    The primary reason for limiting the labels to 23 characters
    was so they could be directly contained in CIPSO category sets.
    This is still done were possible, but for labels that are too
    large a mapping is required. This is perfectly safe for communication
    that stays "on the box" and doesn't require much coordination
    between boxes beyond what would have been required to keep label
    names consistent.

    The bulk of this patch is in smackfs, adding and updating
    administrative interfaces. Because existing APIs can't be
    changed new ones that do much the same things as old ones
    have been introduced.

    The Smack specific CIPSO data representation has been removed
    and replaced with the data format used by netlabel. The CIPSO
    header is now computed when a label is imported rather than
    on use. This results in improved IP performance. The smack
    label is now allocated separately from the containing structure,
    allowing for larger strings.

    Four new /smack interfaces have been introduced as four
    of the old interfaces strictly required labels be specified
    in fixed length arrays.

    The access interface is supplemented with the check interface:
        access  "Subject                 Object                  rwxat"
        access2 "Subject Object rwaxt"

    The load interface is supplemented with the rules interface:
        load   "Subject                 Object                  rwxat"
        load2  "Subject Object rwaxt"

    The load-self interface is supplemented with the self-rules interface:
        load-self   "Subject                 Object                  rwxat"
        load-self2  "Subject Object rwaxt"

    The cipso interface is supplemented with the wire interface:
        cipso  "Subject                  lvl cnt  c1  c2 ..."
        cipso2 "Subject lvl cnt  c1  c2 ..."

    The old interfaces are maintained for compatibility.

    Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>


--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html