[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL} Smack: changes for linux 3.5



On Mon, 14 May 2012, Casey Schaufler wrote:

> 
> 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

Applied.

Did you use git-request-pull for this?


> 
> 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>
> 
> 

-- 
James Morris
<jmorris@xxxxxxxxx>
--
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


[Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

Powered by Linux