Casey Schaufler | 24 May 03:34

[PATCH] Smack: Maintainer Record

From: Casey Schaufler <casey <at> schaufler-ca.com>
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 <casey <at> schaufler-ca.com>

---

 MAINTAINERS |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index d7ca204..ccc8a14 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6133,6 +6133,15 @@ S:	Maintained
 F:	include/linux/sl?b*.h
 F:	mm/sl?b.c

+SMACK SECURITY MODULE
+M:	Casey Schaufler <casey <at> schaufler-ca.com>
+L:	linux-security-module <at> 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/
(Continue reading)

Casey Schaufler | 24 May 02:46

[PATCH] Smack: fix smack_new_inode bogosities

From: Casey Schaufler <casey <at> schaufler-ca.com>
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 <casey <at> schaufler-ca.com>

---

 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 cc361b8..76feb31 100644
--- a/security/smack/smack.h
+++ b/security/smack/smack.h
(Continue reading)

David Howells | 23 May 01:02
Picon
Favicon

[PATCH 00/23] Crypto keys and module signing


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

===============
<<< WARNING >>>
===============

    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 (by both strip -x -g and
eu-strip) before being signed.  This appears to result in the smallest,
still-viable module possible.

However, all debug information is discarded, along with chunks of the symbol
and string tables that might otherwise be useful.  An unstripped, unsigned copy
(Continue reading)

James Morris | 22 May 04:24
Favicon

[GIT] Security subsystem updates for 3.5

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
(Continue reading)

Eric Paris | 21 May 22:19
Picon
Favicon

[GIT PULL] SELinux changes intended for 3.5

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_permission
      SELinux: remove inode_has_perm_noadp
      SELinux: move common_audit_data to a noinline slow path function
      LSM: remove the COMMON_AUDIT_DATA_INIT type expansion
      apparmor: move task from common_audit_data to apparmor_audit_data
      LSM: remove the task field from common_audit_data
      LSM: BUILD_BUG_ON if the common_audit_data union ever grows
      LSM: do not initialize common_audit_data to 0
      SELinux: remove auditdeny from selinux_audit_data
(Continue reading)

Eric Paris | 21 May 20:21

seccomp and ptrace. what is the correct order?

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 <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jarkko Sakkinen | 21 May 19:49
Picon
Favicon

[PATCH] x86, relocs: build clean fix

relocs was not cleaned up when "make clean" is issued. This
patch fixes the issue.

Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen <at> intel.com>
---
 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
@@ -206,6 +206,7 @@ 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)'
--

-- 
1.7.9.5

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

David Howells | 21 May 14:06
Picon
Favicon

[PATCH] [RFC] KEYS: Make the session and process keyrings per-thread [ver #2]

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_NOTIFY_RESUME and key_replace_session_keyring() to get
     another thread to replace its keyring, but that means preallocating for
     each thread.

A reasonable way around this is to make the session keyring per-thread rather
than per-process and just document that if you want a common session keyring,
you must get it before you spawn any threads - which is the current situation
(Continue reading)

David Howells | 21 May 13:32
Picon
Favicon

[PATCH] KEYS: Fix some sparse warnings

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 <dhowells <at> redhat.com>
---

 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
--- a/security/keys/compat.c
+++ b/security/keys/compat.c
(Continue reading)

David Howells | 21 May 12:32
Picon
Favicon

[PATCH] [RFC] KEYS: Make the session and process keyrings per-thread

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_NOTIFY_RESUME and key_replace_session_keyring() to get
     another thread to replace its keyring, but that means preallocating for
     each thread.

A reasonable way around this is to make the session keyring per-thread rather
than per-process and just document that if you want a common session keyring,
you must get it before you spawn any threads - which is the current situation
(Continue reading)

Jeffrin Jose | 20 May 20:23
Picon
Favicon
Gravatar

[PATCH]security:selinux:fixed spacing issues relating to : and ? operators.

Fixed spacing issues of : and ? operators found by
checkpatch.pl in security/selinux/xfrm.c

Signed-off-by: Jeffrin Jose <ahiliation <at> yahoo.co.in>
---
 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
@@ -140,7 +140,7 @@ int selinux_xfrm_state_pol_flow_match(struct xfrm_state *x, struct xfrm_policy *

 	rc = avc_has_perm(fl->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
--

-- 
1.7.10

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

(Continue reading)


Gmane