1. 18 May, 2012 2 commits
  2. 16 May, 2012 1 commit
  3. 15 May, 2012 6 commits
    • David Howells's avatar
      KEYS: Don't check for NULL key pointer in key_validate() · b404aef7
      David Howells authored
      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: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      b404aef7
    • Casey Schaufler's avatar
      Smack: allow for significantly longer Smack labels v4 · f7112e6c
      Casey Schaufler authored
      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: default avatarCasey Schaufler <casey@schaufler-ca.com>
      f7112e6c
    • Tetsuo Handa's avatar
      gfp flags for security_inode_alloc()? · ceffec55
      Tetsuo Handa authored
      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: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarCasey Schaufler <cschaufler@cschaufler-intel.(none)>
      ceffec55
    • Casey Schaufler's avatar
      Smack: recursive tramsmute · 2267b13a
      Casey Schaufler authored
      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: default avatarCasey Schaufler <casey@schaufler-ca.com>
      2267b13a
    • Kees Cook's avatar
      Yama: replace capable() with ns_capable() · 2cc8a716
      Kees Cook authored
      When checking capabilities, the question we want to be asking is "does
      current() have the capability in the child's namespace?"
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      2cc8a716
    • Tetsuo Handa's avatar
      TOMOYO: Accept manager programs which do not start with / . · 77b513dd
      Tetsuo Handa authored
      The pathname of /usr/sbin/tomoyo-editpolicy seen from Ubuntu 12.04 Live CD is
      squashfs:/usr/sbin/tomoyo-editpolicy rather than /usr/sbin/tomoyo-editpolicy .
      Therefore, we need to accept manager programs which do not start with / .
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      77b513dd
  4. 11 May, 2012 7 commits
    • David Howells's avatar
      KEYS: Add invalidation support · fd75815f
      David Howells authored
      Add support for invalidating a key - which renders it immediately invisible to
      further searches and causes the garbage collector to immediately wake up,
      remove it from keyrings and then destroy it when it's no longer referenced.
      
      It's better not to do this with keyctl_revoke() as that marks the key to start
      returning -EKEYREVOKED to searches when what is actually desired is to have the
      key refetched.
      
      To invalidate a key the caller must be granted SEARCH permission by the key.
      This may be too strict.  It may be better to also permit invalidation if the
      caller has any of READ, WRITE or SETATTR permission.
      
      The primary use for this is to evict keys that are cached in special keyrings,
      such as the DNS resolver or an ID mapper.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      fd75815f
    • David Howells's avatar
      KEYS: Do LRU discard in full keyrings · 31d5a79d
      David Howells authored
      Do an LRU discard in keyrings that are full rather than returning ENFILE.  To
      perform this, a time_t is added to the key struct and updated by the creation
      of a link to a key and by a key being found as the result of a search.  At the
      completion of a successful search, the keyrings in the path between the root of
      the search and the first found link to it also have their last-used times
      updated.
      
      Note that discarding a link to a key from a keyring does not necessarily
      destroy the key as there may be references held by other places.
      
      An alternate discard method that might suffice is to perform FIFO discard from
      the keyring, using the spare 2-byte hole in the keylist header as the index of
      the next link to be discarded.
      
      This is useful when using a keyring as a cache for DNS results or foreign
      filesystem IDs.
      
      
      This can be tested by the following.  As root do:
      
      	echo 1000 >/proc/sys/kernel/keys/root_maxkeys
      
      	kr=`keyctl newring foo @s`
      	for ((i=0; i<2000; i++)); do keyctl add user a$i a $kr; done
      
      Without this patch ENFILE should be reported when the keyring fills up.  With
      this patch, the keyring discards keys in an LRU fashion.  Note that the stored
      LRU time has a granularity of 1s.
      
      After doing this, /proc/key-users can be observed and should show that most of
      the 2000 keys have been discarded:
      
      	[root@andromeda ~]# cat /proc/key-users
      	    0:   517 516/516 513/1000 5249/20000
      
      The "513/1000" here is the number of quota-accounted keys present for this user
      out of the maximum permitted.
      
      In /proc/keys, the keyring shows the number of keys it has and the number of
      slots it has allocated:
      
      	[root@andromeda ~]# grep foo /proc/keys
      	200c64c4 I--Q--     1 perm 3b3f0000     0     0 keyring   foo: 509/509
      
      The maximum is (PAGE_SIZE - header) / key pointer size.  That's typically 509
      on a 64-bit system and 1020 on a 32-bit system.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      31d5a79d
    • David Howells's avatar
      KEYS: Permit in-place link replacement in keyring list · 233e4735
      David Howells authored
      Make use of the previous patch that makes the garbage collector perform RCU
      synchronisation before destroying defunct keys.  Key pointers can now be
      replaced in-place without creating a new keyring payload and replacing the
      whole thing as the discarded keys will not be destroyed until all currently
      held RCU read locks are released.
      
      If the keyring payload space needs to be expanded or contracted, then a
      replacement will still need allocating, and the original will still have to be
      freed by RCU.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      233e4735
    • David Howells's avatar
      KEYS: Perform RCU synchronisation on keys prior to key destruction · 65d87fe6
      David Howells authored
      Make the keys garbage collector invoke synchronize_rcu() prior to destroying
      keys with a zero usage count.  This means that a key can be examined under the
      RCU read lock in the safe knowledge that it won't get deallocated until after
      the lock is released - even if its usage count becomes zero whilst we're
      looking at it.
      
      This is useful in keyring search vs key link.  Consider a keyring containing a
      link to a key.  That link can be replaced in-place in the keyring without
      requiring an RCU copy-and-replace on the keyring contents without breaking a
      search underway on that keyring when the displaced key is released, provided
      the key is actually destroyed only after the RCU read lock held by the search
      algorithm is released.
      
      This permits __key_link() to replace a key without having to reallocate the key
      payload.  A key gets replaced if a new key being linked into a keyring has the
      same type and description.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJeff Layton <jlayton@redhat.com>
      65d87fe6
    • David Howells's avatar
      KEYS: Announce key type (un)registration · 1eb1bcf5
      David Howells authored
      Announce the (un)registration of a key type in the core key code rather than
      in the callers.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@us.ibm.com>
      1eb1bcf5
    • David Howells's avatar
      KEYS: Reorganise keys Makefile · 9f7ce8e2
      David Howells authored
      Reorganise the keys directory Makefile to put all the core bits together and
      the type-specific bits after.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@us.ibm.com>
      9f7ce8e2
    • David Howells's avatar
      KEYS: Move the key config into security/keys/Kconfig · f0894940
      David Howells authored
      Move the key config into security/keys/Kconfig as there are going to be a lot
      of key-related options.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@us.ibm.com>
      f0894940
  5. 08 May, 2012 1 commit
    • Pablo Neira Ayuso's avatar
      netfilter: remove ip_queue support · d16cf20e
      Pablo Neira Ayuso authored
      This patch removes ip_queue support which was marked as obsolete
      years ago. The nfnetlink_queue modules provides more advanced
      user-space packet queueing mechanism.
      
      This patch also removes capability code included in SELinux that
      refers to ip_queue. Otherwise, we break compilation.
      
      Several warning has been sent regarding this to the mailing list
      in the past month without anyone rising the hand to stop this
      with some strong argument.
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      d16cf20e
  6. 23 Apr, 2012 1 commit
  7. 19 Apr, 2012 2 commits
  8. 18 Apr, 2012 2 commits
  9. 14 Apr, 2012 2 commits
  10. 10 Apr, 2012 1 commit
  11. 09 Apr, 2012 15 commits