Skip to content
Snippets Groups Projects
  1. Sep 09, 2005
  2. Sep 05, 2005
  3. Sep 01, 2005
  4. Aug 29, 2005
  5. Aug 22, 2005
  6. Aug 04, 2005
    • David Howells's avatar
      [PATCH] Destruction of failed keyring oopses · 94efe72f
      David Howells authored
      
      The attached patch makes sure that a keyring that failed to instantiate
      properly is destroyed without oopsing [CAN-2005-2099].
      
      The problem occurs in three stages:
      
       (1) The key allocator initialises the type-specific data to all zeroes. In
           the case of a keyring, this will become a link in the keyring name list
           when the keyring is instantiated.
      
       (2) If a user (any user) attempts to add a keyring with anything other than
           an empty payload, the keyring instantiation function will fail with an
           error and won't add the keyring to the name list.
      
       (3) The keyring's destructor then sees that the keyring has a description
           (name) and tries to remove the keyring from the name list, which oopses
           because the link pointers are both zero.
      
      This bug permits any user to take down a box trivially.
      
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      94efe72f
    • David Howells's avatar
      [PATCH] Error during attempt to join key management session can leave semaphore pinned · bcf945d3
      David Howells authored
      
      The attached patch prevents an error during the key session joining operation
      from hanging future joins in the D state [CAN-2005-2098].
      
      The problem is that the error handling path for the KEYCTL_JOIN_SESSION_KEYRING
      operation has one error path that doesn't release the session management
      semaphore. Further attempts to get the semaphore will then sleep for ever in
      the D state.
      
      This can happen in four situations, all involving an attempt to allocate a new
      session keyring:
      
       (1) ENOMEM.
      
       (2) The users key quota being reached.
      
       (3) A keyring name that is an empty string.
      
       (4) A keyring name that is too long.
      
      Any user may attempt this operation, and so any user can cause the problem to
      occur.
      
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      bcf945d3
    • David Howells's avatar
      [PATCH] Keys: Fix key management syscall interface bugs · 1260f801
      David Howells authored
      
      This fixes five bugs in the key management syscall interface:
      
       (1) add_key() returns 0 rather than EINVAL if the key type is "".
      
           Checking the key type isn't "" should be left to lookup_user_key().
      
       (2) request_key() returns ENOKEY rather than EPERM if the key type begins
           with a ".".
      
           lookup_user_key() can't do this because internal key types begin with a
           ".".
      
       (3) Key revocation always returns 0, even if it fails.
      
       (4) Key read can return EAGAIN rather than EACCES under some circumstances.
      
           A key is permitted to by read by a process if it doesn't grant read
           access, but it does grant search access and it is in the process's
           keyrings. That search returns EAGAIN if it fails, and this needs
           translating to EACCES.
      
       (5) request_key() never adds the new key to the destination keyring if one is
           supplied.
      
           The wrong macro was being used to test for an error condition: PTR_ERR()
           will always return true, whether or not there's an error; this should've
           been IS_ERR().
      
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-Off-By: default avatarLinus Torvalds <torvalds@osdl.org>
      1260f801
  7. Jul 28, 2005
  8. Jul 08, 2005
    • serue@us.ibm.com's avatar
      [PATCH] seclvl securityfs · 5a73c308
      serue@us.ibm.com authored
      
      Once again, the simple_attr in libfs was actually sufficient - I'd
      thought the __attribute__(format(printk(1,2))) was more mysterious than
      it really is.
      
      At last, here is the full patch to make seclvl use securityfs.
      
      Signed-off-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      --
      
       seclvl.c |  228 +++++++++++++++++++--------------------------------------------
       1 files changed, 70 insertions(+), 158 deletions(-)
      
      Index: linux-2.6.13-rc1/security/seclvl.c
      ===================================================================
      5a73c308
    • Greg Kroah-Hartman's avatar
      [PATCH] add securityfs for all LSMs to use · b67dbf9d
      Greg Kroah-Hartman authored
      
      Here's a small patch against 2.6.13-rc2 that adds securityfs, a virtual
      fs that all LSMs can use instead of creating their own.  The fs should
      be mounted at /sys/kernel/security, and the fs creates that mount point.
      This will make the LSB people happy that we aren't creating a new
      /my_lsm_fs directory in the root for every different LSM.
      
      It has changed a bit since the last version, thanks to comments from
      Mike Waychison.
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      b67dbf9d
  9. Jul 07, 2005
  10. Jun 30, 2005
    • Eric Paris's avatar
      [PATCH] selinux_sb_copy_data() should not require a whole page · 6931dfc9
      Eric Paris authored
      
      Currently selinux_sb_copy_data requires an entire page be allocated to
      *orig when the function is called.  This "requirement" is based on the fact
      that we call copy_page(in_save, nosec_save) and in_save = orig when the
      data is not FS_BINARY_MOUNTDATA.  This means that if a caller were to call
      do_kern_mount with only about 10 bytes of options, they would get passed
      here and then we would corrupt PAGE_SIZE - 10 bytes of memory (with all
      zeros.)
      
      Currently it appears all in kernel FS's use one page of data so this has
      not been a problem.  An out of kernel FS did just what is described above
      and it would almost always panic shortly after they tried to mount.  From
      looking else where in the kernel it is obvious that this string of data
      must always be null terminated.  (See example in do_mount where it always
      zeros the last byte.) Thus I suggest we use strcpy in place of copy_page.
      In this way we make sure the amount we copy is always less than or equal to
      the amount we received and since do_mount is zeroing the last byte this
      should be safe for all.
      
      Signed-off-by: default avatarEric Paris <eparis@parisplace.org>
      Cc: Stephen Smalley <sds@epoch.ncsc.mil>
      Acked-by: default avatarJames Morris <jmorris@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6931dfc9
  11. Jun 25, 2005
  12. Jun 24, 2005
    • Michael Halcrow's avatar
      [PATCH] eCryptfs: export user key type · 16c29b67
      Michael Halcrow authored
      
      Export this symbol to GPL modules for eCryptfs: an out-of-tree GPL'ed
      filesystem.
      
      Signed off by: Michael Halcrow <mhalcrow@us.ibm.com>
      
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      16c29b67
    • David Howells's avatar
      [PATCH] Keys: Make request-key create an authorisation key · 3e30148c
      David Howells authored
      
      The attached patch makes the following changes:
      
       (1) There's a new special key type called ".request_key_auth".
      
           This is an authorisation key for when one process requests a key and
           another process is started to construct it. This type of key cannot be
           created by the user; nor can it be requested by kernel services.
      
           Authorisation keys hold two references:
      
           (a) Each refers to a key being constructed. When the key being
           	 constructed is instantiated the authorisation key is revoked,
           	 rendering it of no further use.
      
           (b) The "authorising process". This is either:
      
           	 (i) the process that called request_key(), or:
      
           	 (ii) if the process that called request_key() itself had an
           	      authorisation key in its session keyring, then the authorising
           	      process referred to by that authorisation key will also be
           	      referred to by the new authorisation key.
      
      	 This means that the process that initiated a chain of key requests
      	 will authorise the lot of them, and will, by default, wind up with
      	 the keys obtained from them in its keyrings.
      
       (2) request_key() creates an authorisation key which is then passed to
           /sbin/request-key in as part of a new session keyring.
      
       (3) When request_key() is searching for a key to hand back to the caller, if
           it comes across an authorisation key in the session keyring of the
           calling process, it will also search the keyrings of the process
           specified therein and it will use the specified process's credentials
           (fsuid, fsgid, groups) to do that rather than the calling process's
           credentials.
      
           This allows a process started by /sbin/request-key to find keys belonging
           to the authorising process.
      
       (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
           direct read or search permission if that key is contained within the
           keyrings of a process specified by an authorisation key found within the
           calling process's session keyring, and is searchable using the
           credentials of the authorising process.
      
           This allows a process started by /sbin/request-key to read keys belonging
           to the authorising process.
      
       (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
           KEYCTL_NEGATE will specify a keyring of the authorising process, rather
           than the process doing the instantiation.
      
       (6) One of the process keyrings can be nominated as the default to which
           request_key() should attach new keys if not otherwise specified. This is
           done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
           constants. The current setting can also be read using this call.
      
       (7) request_key() is partially interruptible. If it is waiting for another
           process to finish constructing a key, it can be interrupted. This permits
           a request-key cycle to be broken without recourse to rebooting.
      
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-Off-By: default avatarBenoit Boissinot <benoit.boissinot@ens-lyon.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3e30148c
    • David Howells's avatar
      [PATCH] Keys: Use RCU to manage session keyring pointer · 8589b4e0
      David Howells authored
      
      The attached patch uses RCU to manage the session keyring pointer in struct
      signal_struct.  This means that searching need not disable interrupts and get
      a the sighand spinlock to access this pointer.  Furthermore, by judicious use
      of rcu_read_(un)lock(), this patch also avoids the need to take and put
      refcounts on the session keyring itself, thus saving on even more atomic ops.
      
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8589b4e0
    • David Howells's avatar
      [PATCH] Keys: Pass session keyring to call_usermodehelper() · 7888e7ff
      David Howells authored
      
      The attached patch makes it possible to pass a session keyring through to the
      process spawned by call_usermodehelper().  This allows patch 3/3 to pass an
      authorisation key through to /sbin/request-key, thus permitting better access
      controls when doing just-in-time key creation.
      
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7888e7ff
    • David Howells's avatar
      [PATCH] keys: Discard key spinlock and use RCU for key payload · 76d8aeab
      David Howells authored
      
      The attached patch changes the key implementation in a number of ways:
      
       (1) It removes the spinlock from the key structure.
      
       (2) The key flags are now accessed using atomic bitops instead of
           write-locking the key spinlock and using C bitwise operators.
      
           The three instantiation flags are dealt with with the construction
           semaphore held during the request_key/instantiate/negate sequence, thus
           rendering the spinlock superfluous.
      
           The key flags are also now bit numbers not bit masks.
      
       (3) The key payload is now accessed using RCU. This permits the recursive
           keyring search algorithm to be simplified greatly since no locks need be
           taken other than the usual RCU preemption disablement. Searching now does
           not require any locks or semaphores to be held; merely that the starting
           keyring be pinned.
      
       (4) The keyring payload now includes an RCU head so that it can be disposed
           of by call_rcu(). This requires that the payload be copied on unlink to
           prevent introducing races in copy-down vs search-up.
      
       (5) The user key payload is now a structure with the data following it. It
           includes an RCU head like the keyring payload and for the same reason. It
           also contains a data length because the data length in the key may be
           changed on another CPU whilst an RCU protected read is in progress on the
           payload. This would then see the supposed RCU payload and the on-key data
           length getting out of sync.
      
           I'm tempted to drop the key's datalen entirely, except that it's used in
           conjunction with quota management and so is a little tricky to get rid
           of.
      
       (6) Update the keys documentation.
      
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      76d8aeab
  13. Jun 23, 2005
    • Alan Cox's avatar
      [PATCH] setuid core dump · d6e71144
      Alan Cox authored
      
      Add a new `suid_dumpable' sysctl:
      
      This value can be used to query and set the core dump mode for setuid
      or otherwise protected/tainted binaries. The modes are
      
      0 - (default) - traditional behaviour.  Any process which has changed
          privilege levels or is execute only will not be dumped
      
      1 - (debug) - all processes dump core when possible.  The core dump is
          owned by the current user and no security is applied.  This is intended
          for system debugging situations only.  Ptrace is unchecked.
      
      2 - (suidsafe) - any binary which normally would not be dumped is dumped
          readable by root only.  This allows the end user to remove such a dump but
          not access it directly.  For security reasons core dumps in this mode will
          not overwrite one another or other files.  This mode is appropriate when
          adminstrators are attempting to debug problems in a normal environment.
      
      (akpm:
      
      > > +EXPORT_SYMBOL(suid_dumpable);
      >
      > EXPORT_SYMBOL_GPL?
      
      No problem to me.
      
      > >  	if (current->euid == current->uid && current->egid == current->gid)
      > >  		current->mm->dumpable = 1;
      >
      > Should this be SUID_DUMP_USER?
      
      Actually the feedback I had from last time was that the SUID_ defines
      should go because its clearer to follow the numbers. They can go
      everywhere (and there are lots of places where dumpable is tested/used
      as a bool in untouched code)
      
      > Maybe this should be renamed to `dump_policy' or something.  Doing that
      > would help us catch any code which isn't using the #defines, too.
      
      Fair comment. The patch was designed to be easy to maintain for Red Hat
      rather than for merging. Changing that field would create a gigantic
      diff because it is used all over the place.
      
      )
      
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d6e71144
  14. Jun 22, 2005
    • David Woodhouse's avatar
      AUDIT: Wait for backlog to clear when generating messages. · 9ad9ad38
      David Woodhouse authored
      
      Add a gfp_mask to audit_log_start() and audit_log(), to reduce the
      amount of GFP_ATOMIC allocation -- most of it doesn't need to be 
      GFP_ATOMIC. Also if the mask includes __GFP_WAIT, then wait up to
      60 seconds for the auditd backlog to clear instead of immediately 
      abandoning the message. 
      
      The timeout should probably be made configurable, but for now it'll 
      suffice that it only happens if auditd is actually running.
      
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      9ad9ad38
  15. Jun 21, 2005
  16. Jun 20, 2005
  17. Jun 18, 2005
    • Thomas Graf's avatar
      [NETLINK]: Neighbour table configuration and statistics via rtnetlink · c7fb64db
      Thomas Graf authored
      
      To retrieve the neighbour tables send RTM_GETNEIGHTBL with the
      NLM_F_DUMP flag set. Every neighbour table configuration is
      spread over multiple messages to avoid running into message
      size limits on systems with many interfaces. The first message
      in the sequence transports all not device specific data such as
      statistics, configuration, and the default parameter set.
      This message is followed by 0..n messages carrying device
      specific parameter sets.
      
      Although the ordering should be sufficient, NDTA_NAME can be
      used to identify sequences. The initial message can be identified
      by checking for NDTA_CONFIG. The device specific messages do
      not contain this TLV but have NDTPA_IFINDEX set to the
      corresponding interface index.
      
      To change neighbour table attributes, send RTM_SETNEIGHTBL
      with NDTA_NAME set. Changeable attribute include NDTA_THRESH[1-3],
      NDTA_GC_INTERVAL, and all TLVs in NDTA_PARMS unless marked
      otherwise. Device specific parameter sets can be changed by
      setting NDTPA_IFINDEX to the interface index of the corresponding
      device.
      
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7fb64db
  18. May 24, 2005
    • Stephen Smalley's avatar
      AUDIT: Fix remaining cases of direct logging of untrusted strings by avc_audit · 37ca5389
      Stephen Smalley authored
      
      Per Steve Grubb's observation that there are some remaining cases where
      avc_audit() directly logs untrusted strings without escaping them, here
      is a patch that changes avc_audit() to use audit_log_untrustedstring()
      or audit_log_hex() as appropriate.  Note that d_name.name is nul-
      terminated by d_alloc(), and that sun_path is nul-terminated by
      unix_mkname(), so it is not necessary for the AVC to create nul-
      terminated copies or to alter audit_log_untrustedstring to take a length
      argument.  In the case of an abstract name, we use audit_log_hex() with
      an explicit length.
      
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      37ca5389
  19. May 21, 2005
Loading