user/sven/linux.git/security/smack, branch v3.6.9

smack: off by one error

2012-07-30T05:04:17Z

Consider the input case of a rule that consists entirely of non space symbols followed by a \0. Say 64 + \0 In this case strlen(data) = 64 kzalloc of subject and object are 64 byte objects sscanfdata, "%s %s %s", subject, ...) will put 65 bytes into subject. Signed-off-by: Alan Cox Acked-by: Casey Schaufler Cc: stable@vger.kernel.org Signed-off-by: James Morris

Smack: don't show empty rules when /smack/load or /smack/load2 is read

2012-07-13T22:49:24Z

This patch removes empty rules (i.e. with access set to '-') from the rule list presented to user space. Smack by design never removes labels nor rules from its lists. Access for a rule may be set to '-' to effectively disable it. Such rules would show up in the listing generated when /smack/load or /smack/load2 is read. This may cause clutter if many rules were disabled. As a rule with access set to '-' is equivalent to no rule at all, they may be safely hidden from the listing. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Rafal Krypa Signed-off-by: Casey Schaufler

Smack: user access check bounds

2012-07-13T22:49:24Z

Some of the bounds checking used on the /smack/access interface was lost when support for long labels was added. No kernel access checks are affected, however this is a case where /smack/access could be used incorrectly and fail to detect the error. This patch reintroduces the original checks. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler

Smack: onlycap limits on CAP_MAC_ADMIN

2012-07-13T22:49:23Z

Smack is integrated with the POSIX capabilities scheme, using the capabilities CAP_MAC_OVERRIDE and CAP_MAC_ADMIN to determine if a process is allowed to ignore Smack checks or change Smack related data respectively. Smack provides an additional restriction that if an onlycap value is set by writing to /smack/onlycap only tasks with that Smack label are allowed to use CAP_MAC_OVERRIDE. This change adds CAP_MAC_ADMIN as a capability that is affected by the onlycap mechanism. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler

Smack: fix smack_new_inode bogosities

2012-07-13T22:49:23Z

In January of 2012 Al Viro pointed out three bits of code that he titled "new_inode_smack bogosities". This patch repairs these errors. 1. smack_sb_kern_mount() included a NULL check that is impossible. The check and NULL case are removed. 2. smack_kb_kern_mount() included pointless locking. The locking is removed. Since this is the only place that lock was used the lock is removed from the superblock_smack structure. 3. smk_fill_super() incorrectly and unnecessarily set the Smack label for the smackfs root inode. The assignment has been removed. Targeted for git://gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler

split ->file_mmap() into ->mmap_addr()/->mmap_file()

2012-05-31T17:11:54Z

... i.e. file-dependent and address-dependent checks. Signed-off-by: Al Viro

split cap_mmap_addr() out of cap_file_mmap()

2012-05-31T17:10:54Z

... switch callers. Signed-off-by: Al Viro

Merge branch 'master' of git://git.infradead.org/users/eparis/selinux into next

2012-05-22T01:21:06Z

Per pull request, for 3.5.

Smack: allow for significantly longer Smack labels v4

2012-05-15T05:48:38Z

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

gfp flags for security_inode_alloc()?

2012-05-15T05:47:44Z

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 Signed-off-by: Casey Schaufler