http://blog.gmane.org/gmane.linux.kernel.lsm hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.kernel.lsm/16468 <pre>From: Casey Schaufler &lt;casey&lt; at &gt;schaufler-ca.com&gt; Subject: [PATCH] Smack: Maintainer Record Add a maintainer record for the Smack LSM. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler &lt;casey&lt; at &gt;schaufler-ca.com&gt; --- MAINTAINERS | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d7ca204..ccc8a14 100644 --- a/MAINTAINERS +++ b/MAINTAINERS &lt; at &gt;&lt; at &gt; -6133,6 +6133,15 &lt; at &gt;&lt; at &gt; S:Maintained F:include/linux/sl?b*.h F:mm/sl?b.c +SMACK SECURITY MODULE +M:Casey Schaufler &lt;casey&lt; at &gt;schaufler-ca.com&gt; +L:linux-security-module&lt; at &gt;vger.kernel.org +W:http://schaufler-ca.com +T:git git://git.gitorious.org/smack-next/kernel.git +S:Maintained +F:Documentation/security/Smack.txt +F:security/smack/ + SMC91x ETHERNET DRIVER M:Nicolas Pitre &lt;nico&lt; at &gt;fluxnic.net&gt; S:Odd Fixes -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info a</pre> Casey Schaufler 2012-05-24T01:34:52 http://comments.gmane.org/gmane.linux.kernel.lsm/16467 <pre>From: Casey Schaufler &lt;casey&lt; at &gt;schaufler-ca.com&gt; Subject: [PATCH] Smack: fix smack_new_inode bogosities 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 &lt;casey&lt; at &gt;schaufler-ca.com&gt; --- security/smack/smack.h | 1 - security/smack/smack_lsm.c | 8 ++------ security/smack/smackfs.c | 1 - 3 files changed, 2 insertions(+), 8 deletions(-) diff --git a/security/smack/smack.h b/security/smack/smack.h index</pre> Casey Schaufler 2012-05-24T00:46:58 http://comments.gmane.org/gmane.linux.kernel.lsm/16436 <pre> Okay Rusty, Here's a set of patches that does module signing attaching the signature in the way you wanted. I do not agree with doing it this way. However, as you insisted rather forcefully... =============== &lt;&lt;&lt; WARNING &gt;&gt;&gt; =============== Anyone wanting to use the module signing facility contained in these patches MUST FIRST make sure that modules are not stripped after being signed. This includes by packaging systems (such as rpmbuild) extracting debug information and due to size reduction for initramfs composition. This is likely to require alterations to userspace packages, both on the build machine and the installed machine. If the module is passed through strip, but the signature is _not_ discarded, then the module load will be rejected, potentially resulting in an unbootable machine. If you are in FIPS mode the kernel will panic. To make the modules more usable from an initramfs (which may have limited capacity), the module files are maximally stripped </pre> David Howells 2012-05-22T23:02:19 http://comments.gmane.org/gmane.linux.kernel.lsm/16421 <pre>Hi Linus, New notable features: - The seccomp work from Will Drewry - PR_{GET,SET}_NO_NEW_PRIVS from Andy Lutomirski - Longer security labels for Smack from Casey Schaufler - Additional ptrace restriction modes for Yama by Kees Cook Please pull. The following changes since commit 76e10d158efb6d4516018846f60c2ab5501900bc: Linus Torvalds (1): Linux 3.4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next Andy Lutomirski (1): Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs Casey Schaufler (2): Smack: recursive tramsmute Smack: allow for significantly longer Smack labels v4 Dan Carpenter (1): Yama: remove an unused variable David Howells (9): KEYS: Use the compat keyctl() syscall wrapper on Sparc64 for Sparc32 compat KEYS: Move the key config into security/keys/Kconfig KEYS: Reorganise keys Makefile KEYS: Announce key type (un)registration KEYS: Perf</pre> James Morris 2012-05-22T02:24:22 http://comments.gmane.org/gmane.linux.kernel.lsm/16417 <pre>Been in next for a month and a half. Just checked and merge should be clean. The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e: Linux 3.4-rc2 (2012-04-07 18:30:41 -0700) are available in the git repository at: git://git.infradead.org/users/eparis/selinux.git master Eric Paris (22): SELinux: allow seek operations on the file exposing policy SELinux: loosen DAC perms on reading policy SELinux: include flow.h where used rather than get it indirectly SELinux: allow default source/target selectors for user/role/range SELinux: add default_type statements SELinux: check OPEN on truncate calls SELinux: rename dentry_open to file_open SELinux: audit failed attempts to set invalid labels SELinux: possible NULL deref in context_struct_to_string SELinux: remove needless sel_div function SELinux: if sel_make_bools errors don't leave inconsistent state SELinux: delay initialization of audit data in selinux_inode_per</pre> Eric Paris 2012-05-21T20:19:03 http://comments.gmane.org/gmane.linux.kernel.lsm/16411 <pre>Viro ask me a question today and I didn't have a good answer. Lets assume I set a seccomp filter that will allow read and will deny/kill ioctl. If something else is tracing me I could call read. The read will pass the seccomp hook and move onto the ptrace hook. The tracer could then change the syscall number to ioctl and I would then actually perform an ioctl. Is that what we want? Do we want to do the permission check based on what a process ask at syscall enter or do we want to do the permission check based on what the kernel is actually going to do on behalf of the process? Does the question make sense? -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Eric Paris 2012-05-21T18:21:57 http://comments.gmane.org/gmane.linux.kernel.lsm/16410 <pre>relocs was not cleaned up when "make clean" is issued. This patch fixes the issue. Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen&lt; at &gt;intel.com&gt; --- arch/x86/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 94e91e4..b1c611e 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile &lt; at &gt;&lt; at &gt; -206,6 +206,7 &lt; at &gt;&lt; at &gt; archclean: $(Q)rm -rf $(objtree)/arch/i386 $(Q)rm -rf $(objtree)/arch/x86_64 $(Q)$(MAKE) $(clean)=$(boot) +$(Q)$(MAKE) $(clean)=arch/x86/tools define archhelp echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)' </pre> Jarkko Sakkinen 2012-05-21T17:49:03 http://comments.gmane.org/gmane.linux.kernel.lsm/16409 <pre>Make the session keyring per-thread rather than per-process, but still inherited from the parent thread to solve a problem with PAM and gdm. The problem is that join_session_keyring() will reject attempts to change the session keyring of a multithreaded program but gdm is now multithreaded before it gets to the point of starting PAM and running pam_keyinit to create the session keyring. See: https://bugs.freedesktop.org/show_bug.cgi?id=49211 The reason that join_session_keyring() will only change the session keyring under a single-threaded environment is that it's hard to alter the other thread's credentials to effect the change in a multi-threaded program. The problems are such as: (1) How to prevent two threads both running join_session_keyring() from racing. (2) Another thread's credentials may not be modified directly by this process. (3) The number of threads is uncertain whilst we're not holding the appropriate spinlock, making preallocation slightly tricky. (4) We could use TIF</pre> David Howells 2012-05-21T12:06:18 http://comments.gmane.org/gmane.linux.kernel.lsm/16407 <pre>Fix some sparse warnings in the keyrings code: (1) compat_keyctl_instantiate_key_iov() should be static. (2) There were a couple of places where a pointer was being compared against integer 0 rather than NULL. (3) keyctl_instantiate_key_common() should not take a __user-labelled iovec pointer as the caller must have copied the iovec to kernel space. (4) __key_link_begin() takes and __key_link_end() releases keyring_serialise_link_sem under some circumstances and so this should be declared. Note that adding __acquires() and __releases() for this doesn't help cure the warnings messages - something only commenting out both helps. Signed-off-by: David Howells &lt;dhowells&lt; at &gt;redhat.com&gt; --- security/keys/compat.c | 4 ++-- security/keys/internal.h | 2 +- security/keys/keyctl.c | 2 +- security/keys/keyring.c | 2 ++ 4 files changed, 6 insertions(+), 4 deletions(-) diff --git a/security/keys/compat.c b/security/keys/compat.c index fab4f8d..e35ae1d 100644 --- </pre> David Howells 2012-05-21T11:32:13 http://comments.gmane.org/gmane.linux.kernel.lsm/16406 <pre>Make the session keyring per-thread rather than per-process, but still inherited from the parent thread to solve a problem with PAM and gdm. The problem is that join_session_keyring() will reject attempts to change the session keyring of a multithreaded program but gdm is now multithreaded before it gets to the point of starting PAM and running pam_keyinit to create the session keyring. See: https://bugs.freedesktop.org/show_bug.cgi?id=49211 The reason that join_session_keyring() will only change the session keyring under a single-threaded environment is that it's hard to alter the other thread's credentials to effect the change in a multi-threaded program. The problems are such as: (1) How to prevent two threads both running join_session_keyring() from racing. (2) Another thread's credentials may not be modified directly by this process. (3) The number of threads is uncertain whilst we're not holding the appropriate spinlock, making preallocation slightly tricky. (4) We could use TIF</pre> David Howells 2012-05-21T10:32:50 http://comments.gmane.org/gmane.linux.kernel.lsm/16400 <pre>Fixed spacing issues of : and ? operators found by checkpatch.pl in security/selinux/xfrm.c Signed-off-by: Jeffrin Jose &lt;ahiliation&lt; at &gt;yahoo.co.in&gt; --- security/selinux/xfrm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/selinux/xfrm.c b/security/selinux/xfrm.c index 48665ec..a3cb878 100644 --- a/security/selinux/xfrm.c +++ b/security/selinux/xfrm.c &lt; at &gt;&lt; at &gt; -140,7 +140,7 &lt; at &gt;&lt; at &gt; int selinux_xfrm_state_pol_flow_match(struct xfrm_state *x, struct xfrm_policy * rc = avc_has_perm(fl-&gt;flowi_secid, state_sid, SECCLASS_ASSOCIATION, ASSOCIATION__SENDTO, - NULL)? 0:1; + NULL) ? 0 : 1; /* * We don't need a separate SA Vs. policy polmatch check </pre> Jeffrin Jose 2012-05-20T18:23:49 http://comments.gmane.org/gmane.linux.kernel.lsm/16388 <pre>For the purposes of tracking malware in an enterprise, I'm interested in logging the hash of binaries as they are exec'd. The following patch (mostly) adds this functionality. When a binary is executed, gih_file_check is called which checks to see if this inode has been exec'd before. If not, it's sha1 hash is taken and logged to auditd along with its pid, ppid, uid, euid, loginuid &amp; path and the inode is stored the list of previously hashed binaries. Subsequent exec's incur no extra hashing. There's still some work to be done on this, eg finding a more efficient way to search exec'd inodes, making sure there are no memory leaks, etc. In the meantime, I'm interested in knowing if other people/organizations are interested in this feature and also on my approach to solving the problem. Are there any obvious issues that I'm missing because I'm new at this, etc? If code looks similar to IMA at all, that's because I borrowed a fair bit of it directly from IMA. Since IMA already does the hashing I've was lookin</pre> Peter Moody 2012-05-18T22:58:42 http://comments.gmane.org/gmane.linux.kernel.lsm/16380 <pre>Add a simple trace event for capable(). There's been a lot of discussion around capable(), and there are plenty of tools to help reduce capabilities' usage from userspace. A major gap however is that it's almost impossible to see or verify which bits are requested from either userspace or in the kernel. This patch adds a minimal tracer that will print out which CAPs are requested and whether the request was granted. Signed-off-by: Auke Kok &lt;auke-jan.h.kok&lt; at &gt;intel.com&gt; Cc: linux-security-module&lt; at &gt;vger.kernel.org Cc: linux-kernel&lt; at &gt;vger.kernel.org Cc: Serge Hallyn &lt;serge.hallyn&lt; at &gt;canonical.com&gt; Cc: Eric Paris &lt;eparis&lt; at &gt;redhat.com&gt; --- include/trace/events/capabilities.h | 33 +++++++++++++++++++++++++++++++++ kernel/capability.c | 5 +++++ 2 files changed, 38 insertions(+) create mode 100644 include/trace/events/capabilities.h diff --git a/include/trace/events/capabilities.h b/include/trace/events/capabilities.h new file mode 100644 index 0000000..97997fa --- /dev/null +++ b/include/trace/even</pre> Auke Kok 2012-05-17T19:50:00 http://comments.gmane.org/gmane.linux.kernel.lsm/16344 <pre>Don't bother checking for NULL key pointer in key_validate() as all of the places that call it will crash anyway if the relevant key pointer is NULL by the time they call key_validate(). Therefore, the checking must be done prior to calling here. Whilst we're at it, simplify the key_validate() function a bit and mark its argument const. Reported-by: Dan Carpenter &lt;dan.carpenter&lt; at &gt;oracle.com&gt; Signed-off-by: David Howells &lt;dhowells&lt; at &gt;redhat.com&gt; cc: Dan Carpenter &lt;dan.carpenter&lt; at &gt;oracle.com&gt; --- include/linux/key.h | 2 +- security/keys/permission.c | 40 ++++++++++++++++------------------------ 2 files changed, 17 insertions(+), 25 deletions(-) diff --git a/include/linux/key.h b/include/linux/key.h index b145b05..52318007 100644 --- a/include/linux/key.h +++ b/include/linux/key.h &lt; at &gt;&lt; at &gt; -242,7 +242,7 &lt; at &gt;&lt; at &gt; extern struct key *request_key_async_with_auxdata(struct key_type *type, extern int wait_for_key_construction(struct key *key, bool intr); -extern int key_validate(struct key *key); +extern int ke</pre> David Howells 2012-05-15T13:11:11 http://comments.gmane.org/gmane.linux.kernel.lsm/16337 <pre> 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 &lt;casey&lt; at &gt;schaufler-ca.com&gt; 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 &lt;casey&lt; at &gt;schaufler-ca.com&gt; commit ceffec5541cc22486d3ff492e3d76a33a68fbfa3 Author: Tetsuo Handa &lt;penguin-kernel&lt; at &gt;I-love.SAKURA.ne.jp&gt; Date: Thu Mar 29 16:19:05 2012 +0900 gfp flags for security_inode_alloc()? Dave Chinner wrote: </pre> Casey Schaufler 2012-05-15T05:37:02 http://comments.gmane.org/gmane.linux.kernel.lsm/16336 <pre>From: Mimi Zohar &lt;zohar&lt; at &gt;us.ibm.com&gt; When IMA was first upstreamed, the bprm filename and interp were always the same. Currently, the bprm-&gt;filename and bprm-&gt;interp are the same, except for when only bprm-&gt;interp contains the interpreter name. So instead of using the bprm-&gt;filename as the IMA filename hint in the measurement list, we could replace it with bprm-&gt;interp, but this feels too fragil. The following patch is not much better, but at least there is some indication that sometimes we're passing the filename and other times the interpreter name. Reported-by: Andrew Lunn &lt;andrew&lt; at &gt;lunn.ch&gt; Signed-off-by: Mimi Zohar &lt;zohar&lt; at &gt;linux.vnet.ibm.com&gt; --- security/integrity/ima/ima_main.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index 1eff5cb..b17be79 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c &lt; at &gt;&lt; at &gt; -194,7 +194,9 &lt; at &gt;&lt; at &gt; int ima_bprm_check(struct linux_binprm *bprm) { </pre> Mimi Zohar 2012-05-15T01:50:11 http://comments.gmane.org/gmane.linux.kernel.lsm/16330 <pre>When checking capabilities, the question we want to be asking is "does current() have the capability in the child's namespace?" Signed-off-by: Kees Cook &lt;keescook&lt; at &gt;chromium.org&gt; --- security/yama/yama_lsm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c index afb04cb..7ba673b 100644 --- a/security/yama/yama_lsm.c +++ b/security/yama/yama_lsm.c &lt; at &gt;&lt; at &gt; -264,11 +264,11 &lt; at &gt;&lt; at &gt; static int yama_ptrace_access_check(struct task_struct *child, case YAMA_SCOPE_RELATIONAL: if (!task_is_descendant(current, child) &amp;&amp; !ptracer_exception_found(current, child) &amp;&amp; - !capable(CAP_SYS_PTRACE)) + !ns_capable(task_user_ns(child), CAP_SYS_PTRACE)) rc = -EPERM; break; case YAMA_SCOPE_CAPABILITY: -if (!capable(CAP_SYS_PTRACE)) +if (!ns_capable(task_user_ns(child), CAP_SYS_PTRACE)) rc = -EPERM; break; case YAMA_SCOPE_NO_ATTACH: </pre> Kees Cook 2012-05-14T17:19:28 http://comments.gmane.org/gmane.linux.kernel.lsm/16325 <pre>From: Mimi Zohar &lt;zohar&lt; at &gt;linux.vnet.ibm.com&gt; This patch has been updated to move the ima_file_mmap() call from security_file_mmap() to the new vm_mmap() function. --- The circular lockdep is caused by allocating the 'iint' for mmapped files. Originally when an 'iint' was allocated for every inode in inode_alloc_security(), before the inode was accessible, no locking was necessary. Commits bc7d2a3e and 196f518 changed this behavior and allocated the 'iint' on a per need basis, resulting in the mmap_sem being taken before the i_mutex for mmapped files. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&amp;mm-&gt;mmap_sem); lock(&amp;sb-&gt;s_type-&gt;i_mutex_key); lock(&amp;mm-&gt;mmap_sem); lock(&amp;sb-&gt;s_type-&gt;i_mutex_key); The existing security_file_mmap() hook is after the mmap_sem is taken. This patch moves the ima_file_mmap() call from security_file_mmap() to prior to the mmap_sem being taken. Changelog </pre> Mimi Zohar 2012-05-14T02:47:11 http://comments.gmane.org/gmane.linux.kernel.lsm/16321 <pre> The next branch of security-testing has: $ git status # On branch next # Changes not staged for commit: # (use "git add &lt;file&gt;..." to update what will be committed) # (use "git checkout -- &lt;file&gt;..." to discard changes in working directory) # # modified: include/linux/netfilter/xt_CONNMARK.h # modified: include/linux/netfilter/xt_DSCP.h # modified: include/linux/netfilter/xt_MARK.h # modified: include/linux/netfilter/xt_RATEEST.h # modified: include/linux/netfilter/xt_TCPMSS.h # modified: include/linux/netfilter_ipv4/ipt_ECN.h # modified: include/linux/netfilter_ipv4/ipt_TTL.h # modified: include/linux/netfilter_ipv6/ip6t_HL.h # modified: net/netfilter/xt_DSCP.c # modified: net/netfilter/xt_HL.c # modified: net/netfilter/xt_RATEEST.c # modified: net/netfilter/xt_TCPMSS.c # no changes added to commit (use "git add" and/or "git commit -a") I think that this needs to get resolved before I can sync up the branc</pre> Casey Schaufler 2012-05-13T21:55:06 http://comments.gmane.org/gmane.linux.kernel.lsm/16319 <pre>From: Subodh Nijsure &lt;snijsure&lt; at &gt;grid-net.com&gt; Also fix couple of bugs in UBIFS extended attribute length calculation. Changes in v4: Fix lock issues introduced in v3. Tested with CONFIG_SECURITY enabled &amp; disabled. Changes in v3: Remove #ifdef CONFIG_UBIFS_FS_XATTR Changes in v2: Instead of just handling security.selinux extended attribute handle all security.* attributes. TESTING: Tested on MX28 based platforms using Micron MT29F2G08ABAEAH4 NAND With these change we are able to label UBIFS filesystem with security.selinux and run system with selinux enabled. This change also allows one to set other security.* extended attributes, such as security.smack security.evm, security.ima Ran integck test on UBI filesystem. This patch set has been tested with CONFIG_LOCKDEP=y and other options suggested in Submitchecklist Signed-off-by: Subodh Nijsure &lt;snijsure&lt; at &gt;grid-net.com&gt; --- fs/ubifs/dir.c | 29 ++++++++</pre> snijsure< at >grid-net.com 2012-05-13T13:24:48 http://comments.gmane.org/gmane.linux.kernel.lsm/16317 <pre>haalloo, how are you doing,i hope you are fine,my name is miss abi okom i got your contact and want us to be a good friend, please try and write back to me so that i will give you my pictures and tell you more about me, -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> abi 2012-05-12T17:06:25 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.lsm