1. 28 2月, 2018 1 次提交
  2. 23 2月, 2018 1 次提交
  3. 22 2月, 2018 1 次提交
    • D
      KEYS: Use individual pages in big_key for crypto buffers · d9f4bb1a
      David Howells 提交于
      kmalloc() can't always allocate large enough buffers for big_key to use for
      crypto (1MB + some metadata) so we cannot use that to allocate the buffer.
      Further, vmalloc'd pages can't be passed to sg_init_one() and the aead
      crypto accessors cannot be called progressively and must be passed all the
      data in one go (which means we can't pass the data in one block at a time).
      
      Fix this by allocating the buffer pages individually and passing them
      through a multientry scatterlist to the crypto layer.  This has the bonus
      advantage that we don't have to allocate a contiguous series of pages.
      
      We then vmap() the page list and pass that through to the VFS read/write
      routines.
      
      This can trigger a warning:
      
      	WARNING: CPU: 0 PID: 60912 at mm/page_alloc.c:3883 __alloc_pages_nodemask+0xb7c/0x15f8
      	([<00000000002acbb6>] __alloc_pages_nodemask+0x1ee/0x15f8)
      	 [<00000000002dd356>] kmalloc_order+0x46/0x90
      	 [<00000000002dd3e0>] kmalloc_order_trace+0x40/0x1f8
      	 [<0000000000326a10>] __kmalloc+0x430/0x4c0
      	 [<00000000004343e4>] big_key_preparse+0x7c/0x210
      	 [<000000000042c040>] key_create_or_update+0x128/0x420
      	 [<000000000042e52c>] SyS_add_key+0x124/0x220
      	 [<00000000007bba2c>] system_call+0xc4/0x2b0
      
      from the keyctl/padd/useradd test of the keyutils testsuite on s390x.
      
      Note that it might be better to shovel data through in page-sized lumps
      instead as there's no particular need to use a monolithic buffer unless the
      kernel itself wants to access the data.
      
      Fixes: 13100a72 ("Security: Keys: Big keys stored encrypted")
      Reported-by: NPaul Bunyan <pbunyan@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Kirill Marinushkin <k.marinushkin@gmail.com>
      d9f4bb1a
  4. 13 2月, 2018 1 次提交
    • D
      net: make getname() functions return length rather than use int* parameter · 9b2c45d4
      Denys Vlasenko 提交于
      Changes since v1:
      Added changes in these files:
          drivers/infiniband/hw/usnic/usnic_transport.c
          drivers/staging/lustre/lnet/lnet/lib-socket.c
          drivers/target/iscsi/iscsi_target_login.c
          drivers/vhost/net.c
          fs/dlm/lowcomms.c
          fs/ocfs2/cluster/tcp.c
          security/tomoyo/network.c
      
      Before:
      All these functions either return a negative error indicator,
      or store length of sockaddr into "int *socklen" parameter
      and return zero on success.
      
      "int *socklen" parameter is awkward. For example, if caller does not
      care, it still needs to provide on-stack storage for the value
      it does not need.
      
      None of the many FOO_getname() functions of various protocols
      ever used old value of *socklen. They always just overwrite it.
      
      This change drops this parameter, and makes all these functions, on success,
      return length of sockaddr. It's always >= 0 and can be differentiated
      from an error.
      
      Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.
      
      rpc_sockname() lost "int buflen" parameter, since its only use was
      to be passed to kernel_getsockname() as &buflen and subsequently
      not used in any way.
      
      Userspace API is not changed.
      
          text    data     bss      dec     hex filename
      30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
      30108109 2633612  873672 33615393 200ee21 vmlinux.o
      Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: linux-kernel@vger.kernel.org
      CC: netdev@vger.kernel.org
      CC: linux-bluetooth@vger.kernel.org
      CC: linux-decnet-user@lists.sourceforge.net
      CC: linux-wireless@vger.kernel.org
      CC: linux-rdma@vger.kernel.org
      CC: linux-sctp@vger.kernel.org
      CC: linux-nfs@vger.kernel.org
      CC: linux-x25@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b2c45d4
  5. 12 2月, 2018 1 次提交
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds 提交于
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
      
          for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
          done
      
      with de-mangling cleanups yet to come.
      
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  6. 07 2月, 2018 1 次提交
  7. 02 2月, 2018 1 次提交
  8. 01 2月, 2018 1 次提交
  9. 29 1月, 2018 1 次提交
  10. 19 1月, 2018 1 次提交
  11. 16 1月, 2018 1 次提交
    • K
      usercopy: Allow strict enforcement of whitelists · 2d891fbc
      Kees Cook 提交于
      This introduces CONFIG_HARDENED_USERCOPY_FALLBACK to control the
      behavior of hardened usercopy whitelist violations. By default, whitelist
      violations will continue to WARN() so that any bad or missing usercopy
      whitelists can be discovered without being too disruptive.
      
      If this config is disabled at build time or a system is booted with
      "slab_common.usercopy_fallback=0", usercopy whitelists will BUG() instead
      of WARN(). This is useful for admins that want to use usercopy whitelists
      immediately.
      Suggested-by: NMatthew Garrett <mjg59@google.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      2d891fbc
  12. 14 1月, 2018 1 次提交
  13. 13 1月, 2018 2 次提交
  14. 11 1月, 2018 1 次提交
  15. 08 1月, 2018 1 次提交
  16. 06 1月, 2018 1 次提交
  17. 03 1月, 2018 1 次提交
  18. 02 1月, 2018 1 次提交
    • E
      capabilities: fix buffer overread on very short xattr · dc32b5c3
      Eric Biggers 提交于
      If userspace attempted to set a "security.capability" xattr shorter than
      4 bytes (e.g. 'setfattr -n security.capability -v x file'), then
      cap_convert_nscap() read past the end of the buffer containing the xattr
      value because it accessed the ->magic_etc field without verifying that
      the xattr value is long enough to contain that field.
      
      Fix it by validating the xattr value size first.
      
      This bug was found using syzkaller with KASAN.  The KASAN report was as
      follows (cleaned up slightly):
      
          BUG: KASAN: slab-out-of-bounds in cap_convert_nscap+0x514/0x630 security/commoncap.c:498
          Read of size 4 at addr ffff88002d8741c0 by task syz-executor1/2852
      
          CPU: 0 PID: 2852 Comm: syz-executor1 Not tainted 4.15.0-rc6-00200-gcc0aac99d977 #253
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
          Call Trace:
           __dump_stack lib/dump_stack.c:17 [inline]
           dump_stack+0xe3/0x195 lib/dump_stack.c:53
           print_address_description+0x73/0x260 mm/kasan/report.c:252
           kasan_report_error mm/kasan/report.c:351 [inline]
           kasan_report+0x235/0x350 mm/kasan/report.c:409
           cap_convert_nscap+0x514/0x630 security/commoncap.c:498
           setxattr+0x2bd/0x350 fs/xattr.c:446
           path_setxattr+0x168/0x1b0 fs/xattr.c:472
           SYSC_setxattr fs/xattr.c:487 [inline]
           SyS_setxattr+0x36/0x50 fs/xattr.c:483
           entry_SYSCALL_64_fastpath+0x18/0x85
      
      Fixes: 8db6c34f ("Introduce v3 namespaced file capabilities")
      Cc: <stable@vger.kernel.org> # v4.14+
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Reviewed-by: NSerge Hallyn <serge@hallyn.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      dc32b5c3
  19. 28 12月, 2017 1 次提交
  20. 24 12月, 2017 1 次提交
    • D
      x86/mm/pti: Add Kconfig · 385ce0ea
      Dave Hansen 提交于
      Finally allow CONFIG_PAGE_TABLE_ISOLATION to be enabled.
      
      PARAVIRT generally requires that the kernel not manage its own page tables.
      It also means that the hypervisor and kernel must agree wholeheartedly
      about what format the page tables are in and what they contain.
      PAGE_TABLE_ISOLATION, unfortunately, changes the rules and they
      can not be used together.
      
      I've seen conflicting feedback from maintainers lately about whether they
      want the Kconfig magic to go first or last in a patch series.  It's going
      last here because the partially-applied series leads to kernels that can
      not boot in a bunch of cases.  I did a run through the entire series with
      CONFIG_PAGE_TABLE_ISOLATION=y to look for build errors, though.
      
      [ tglx: Removed SMP and !PARAVIRT dependencies as they not longer exist ]
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David Laight <David.Laight@aculab.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Eduardo Valentin <eduval@amazon.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: aliguori@amazon.com
      Cc: daniel.gruss@iaik.tugraz.at
      Cc: hughd@google.com
      Cc: keescook@google.com
      Cc: linux-mm@kvack.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      385ce0ea
  21. 18 12月, 2017 7 次提交
    • K
      /dev/mem: Add bounce buffer for copy-out · 22ec1a2a
      Kees Cook 提交于
      As done for /proc/kcore in
      
        commit df04abfd ("fs/proc/kcore.c: Add bounce buffer for ktext data")
      
      this adds a bounce buffer when reading memory via /dev/mem. This
      is needed to allow kernel text memory to be read out when built with
      CONFIG_HARDENED_USERCOPY (which refuses to read out kernel text) and
      without CONFIG_STRICT_DEVMEM (which would have refused to read any RAM
      contents at all).
      
      Since this build configuration isn't common (most systems with
      CONFIG_HARDENED_USERCOPY also have CONFIG_STRICT_DEVMEM), this also tries
      to inform Kconfig about the recommended settings.
      
      This patch is modified from Brad Spengler/PaX Team's changes to /dev/mem
      code in the last public patch of grsecurity/PaX based on my understanding
      of the code. Changes or omissions from the original code are mine and
      don't reflect the original grsecurity/PaX code.
      Reported-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Fixes: f5509cc1 ("mm: Hardened usercopy")
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22ec1a2a
    • S
      ima: Use i_version only when filesystem supports it · a2a2c3c8
      Sascha Hauer 提交于
      i_version is only supported by a filesystem when the SB_I_VERSION
      flag is set. This patch tests for the SB_I_VERSION flag before using
      i_version. If we can't use i_version to detect a file change then we
      must assume the file has changed in the last_writer path and remeasure
      it.
      
      On filesystems without i_version support IMA used to measure a file
      only once and didn't detect any changes to a file. With this patch
      IMA now works properly on these filesystems.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      a2a2c3c8
    • J
      integrity: remove unneeded initializations in integrity_iint_cache entries · 02c324a5
      Jeff Layton 提交于
      The init_once routine memsets the whole object to 0, and then
      explicitly sets some of the fields to 0 again. Just remove the explicit
      initializations.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      02c324a5
    • B
      ima: log message to module appraisal error · 9c655be0
      Bruno E. O. Meneguele 提交于
      Simple but useful message log to the user in case of module appraise is
      forced and fails due to the lack of file descriptor, that might be
      caused by kmod calls to compressed modules.
      Signed-off-by: NBruno E. O. Meneguele <brdeoliv@redhat.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      9c655be0
    • R
      ima: pass filename to ima_rdwr_violation_check() · 4e8581ee
      Roberto Sassu 提交于
      ima_rdwr_violation_check() retrieves the full path of a measured file by
      calling ima_d_path(). If process_measurement() calls this function, it
      reuses the pointer and passes it to the functions to measure/appraise/audit
      an accessed file.
      
      After commit bc15ed66 ("ima: fix ima_d_path() possible race with
      rename"), ima_d_path() first tries to retrieve the full path by calling
      d_absolute_path() and, if there is an error, copies the dentry name to the
      buffer passed as argument.
      
      However, ima_rdwr_violation_check() passes to ima_d_path() the pointer of a
      local variable. process_measurement() might be reusing the pointer to an
      area in the stack which may have been already overwritten after
      ima_rdwr_violation_check() returned.
      
      Correct this issue by passing to ima_rdwr_violation_check() the pointer of
      a buffer declared in process_measurement().
      
      Fixes: bc15ed66 ("ima: fix ima_d_path() possible race with rename")
      Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      4e8581ee
    • J
      ima: Fix line continuation format · 72bf83b0
      Joe Perches 提交于
      Line continuations with excess spacing causes unexpected output.
      
      Based on commit 6f76b6fc ("CodingStyle: Document the exception of
      not splitting user-visible strings, for grepping") recommendation.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      72bf83b0
    • M
      ima: support new "hash" and "dont_hash" policy actions · da1b0029
      Mimi Zohar 提交于
      The builtin ima_appraise_tcb policy, which is specified on the boot
      command line, can be replaced with a custom policy, normally early in
      the boot process.  Custom policies can be more restrictive in some ways,
      like requiring file signatures, but can be less restrictive in other
      ways, like not appraising mutable files.  With a less restrictive policy
      in place, files in the builtin policy might not be hashed and labeled
      with a security.ima hash.  On reboot, files which should be labeled in
      the ima_appraise_tcb are not labeled, possibly preventing the system
      from booting properly.
      
      To resolve this problem, this patch extends the existing IMA policy
      actions "measure", "dont_measure", "appraise", "dont_appraise", and
      "audit" with "hash" and "dont_hash".  The new "hash" action will write
      the file hash as security.ima, but without requiring the file to be
      appraised as well.
      
      For example, the builtin ima_appraise_tcb policy includes the rule,
      "appraise fowner=0".  Adding the "hash fowner=0" rule to a custom
      policy, will cause the needed file hashes to be calculated and written
      as security.ima xattrs.
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
      da1b0029
  22. 13 12月, 2017 1 次提交
  23. 12 12月, 2017 4 次提交
    • D
      ima: re-introduce own integrity cache lock · 0d73a552
      Dmitry Kasatkin 提交于
      Before IMA appraisal was introduced, IMA was using own integrity cache
      lock along with i_mutex. process_measurement and ima_file_free took
      the iint->mutex first and then the i_mutex, while setxattr, chmod and
      chown took the locks in reverse order. To resolve the potential deadlock,
      i_mutex was moved to protect entire IMA functionality and the redundant
      iint->mutex was eliminated.
      
      Solution was based on the assumption that filesystem code does not take
      i_mutex further. But when file is opened with O_DIRECT flag, direct-io
      implementation takes i_mutex and produces deadlock. Furthermore, certain
      other filesystem operations, such as llseek, also take i_mutex.
      
      More recently some filesystems have replaced their filesystem specific
      lock with the global i_rwsem to read a file.  As a result, when IMA
      attempts to calculate the file hash, reading the file attempts to take
      the i_rwsem again.
      
      To resolve O_DIRECT related deadlock problem, this patch re-introduces
      iint->mutex. But to eliminate the original chmod() related deadlock
      problem, this patch eliminates the requirement for chmod hooks to take
      the iint->mutex by introducing additional atomic iint->attr_flags to
      indicate calling of the hooks. The allowed locking order is to take
      the iint->mutex first and then the i_rwsem.
      
      Original flags were cleared in chmod(), setxattr() or removwxattr()
      hooks and tested when file was closed or opened again. New atomic flags
      are set or cleared in those hooks and tested to clear iint->flags on
      close or on open.
      
      Atomic flags are following:
      * IMA_CHANGE_ATTR - indicates that chATTR() was called (chmod, chown,
        chgrp) and file attributes have changed. On file open, it causes IMA
        to clear iint->flags to re-evaluate policy and perform IMA functions
        again.
      * IMA_CHANGE_XATTR - indicates that setxattr or removexattr was called
        and extended attributes have changed. On file open, it causes IMA to
        clear iint->flags IMA_DONE_MASK to re-appraise.
      * IMA_UPDATE_XATTR - indicates that security.ima needs to be updated.
        It is cleared if file policy changes and no update is needed.
      * IMA_DIGSIG - indicates that file security.ima has signature and file
        security.ima must not update to file has on file close.
      * IMA_MUST_MEASURE - indicates the file is in the measurement policy.
      
      Fixes: Commit 65523218 ("xfs: remove i_iolock and use i_rwsem in
      the VFS inode instead")
      Signed-off-by: NDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      0d73a552
    • M
      EVM: Add support for portable signature format · 50b97748
      Matthew Garrett 提交于
      The EVM signature includes the inode number and (optionally) the
      filesystem UUID, making it impractical to ship EVM signatures in
      packages. This patch adds a new portable format intended to allow
      distributions to include EVM signatures. It is identical to the existing
      format but hardcodes the inode and generation numbers to 0 and does not
      include the filesystem UUID even if the kernel is configured to do so.
      
      Removing the inode means that the metadata and signature from one file
      could be copied to another file without invalidating it. This is avoided
      by ensuring that an IMA xattr is present during EVM validation.
      
      Portable signatures are intended to be immutable - ie, they will never
      be transformed into HMACs.
      
      Based on earlier work by Dmitry Kasatkin and Mikhail Kurinnoi.
      Signed-off-by: NMatthew Garrett <mjg59@google.com>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Mikhail Kurinnoi <viewizard@viewizard.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      50b97748
    • M
      EVM: Allow userland to permit modification of EVM-protected metadata · ae1ba167
      Matthew Garrett 提交于
      When EVM is enabled it forbids modification of metadata protected by
      EVM unless there is already a valid EVM signature. If any modification
      is made, the kernel will then generate a new EVM HMAC. However, this
      does not map well on use cases which use only asymmetric EVM signatures,
      as in this scenario the kernel is unable to generate new signatures.
      
      This patch extends the /sys/kernel/security/evm interface to allow
      userland to request that modification of these xattrs be permitted. This
      is only permitted if no keys have already been loaded. In this
      configuration, modifying the metadata will invalidate the EVM appraisal
      on the file in question. This allows packaging systems to write out new
      files, set the relevant extended attributes and then move them into
      place.
      
      There's also some refactoring of the use of evm_initialized in order to
      avoid heading down codepaths that assume there's a key available.
      Signed-off-by: NMatthew Garrett <mjg59@google.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      ae1ba167
    • M
      ima: relax requiring a file signature for new files with zero length · b7e27bc1
      Mimi Zohar 提交于
      Custom policies can require file signatures based on LSM labels.  These
      files are normally created and only afterwards labeled, requiring them
      to be signed.
      
      Instead of requiring file signatures based on LSM labels, entire
      filesystems could require file signatures.  In this case, we need the
      ability of writing new files without requiring file signatures.
      
      The definition of a "new" file was originally defined as any file with
      a length of zero.  Subsequent patches redefined a "new" file to be based
      on the FILE_CREATE open flag.  By combining the open flag with a file
      size of zero, this patch relaxes the file signature requirement.
      
      Fixes: 1ac202e9 ima: accept previously set IMA_NEW_FILE
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      b7e27bc1
  24. 08 12月, 2017 4 次提交
    • E
      KEYS: reject NULL restriction string when type is specified · 18026d86
      Eric Biggers 提交于
      keyctl_restrict_keyring() allows through a NULL restriction when the
      "type" is non-NULL, which causes a NULL pointer dereference in
      asymmetric_lookup_restriction() when it calls strcmp() on the
      restriction string.
      
      But no key types actually use a "NULL restriction" to mean anything, so
      update keyctl_restrict_keyring() to reject it with EINVAL.
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Fixes: 97d3aa0f ("KEYS: Add a lookup_restriction function for the asymmetric key type")
      Cc: <stable@vger.kernel.org> # v4.12+
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      18026d86
    • C
      security: keys: remove redundant assignment to key_ref · 3d1f0255
      Colin Ian King 提交于
      Variable key_ref is being assigned a value that is never read;
      key_ref is being re-assigned a few statements later.  Hence this
      assignment is redundant and can be removed.
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NJames Morris <james.l.morris@oracle.com>
      3d1f0255
    • E
      KEYS: add missing permission check for request_key() destination · 4dca6ea1
      Eric Biggers 提交于
      When the request_key() syscall is not passed a destination keyring, it
      links the requested key (if constructed) into the "default" request-key
      keyring.  This should require Write permission to the keyring.  However,
      there is actually no permission check.
      
      This can be abused to add keys to any keyring to which only Search
      permission is granted.  This is because Search permission allows joining
      the keyring.  keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING)
      then will set the default request-key keyring to the session keyring.
      Then, request_key() can be used to add keys to the keyring.
      
      Both negatively and positively instantiated keys can be added using this
      method.  Adding negative keys is trivial.  Adding a positive key is a
      bit trickier.  It requires that either /sbin/request-key positively
      instantiates the key, or that another thread adds the key to the process
      keyring at just the right time, such that request_key() misses it
      initially but then finds it in construct_alloc_key().
      
      Fix this bug by checking for Write permission to the keyring in
      construct_get_dest_keyring() when the default keyring is being used.
      
      We don't do the permission check for non-default keyrings because that
      was already done by the earlier call to lookup_user_key().  Also,
      request_key_and_link() is currently passed a 'struct key *' rather than
      a key_ref_t, so the "possessed" bit is unavailable.
      
      We also don't do the permission check for the "requestor keyring", to
      continue to support the use case described by commit 8bbf4976
      ("KEYS: Alter use of key instantiation link-to-keyring argument") where
      /sbin/request-key recursively calls request_key() to add keys to the
      original requestor's destination keyring.  (I don't know of any users
      who actually do that, though...)
      
      Fixes: 3e30148c ("[PATCH] Keys: Make request-key create an authorisation key")
      Cc: <stable@vger.kernel.org>	# v2.6.13+
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      4dca6ea1
    • E
      KEYS: remove unnecessary get/put of explicit dest_keyring · a2d8737d
      Eric Biggers 提交于
      In request_key_and_link(), in the case where the dest_keyring was
      explicitly specified, there is no need to get another reference to
      dest_keyring before calling key_link(), then drop it afterwards.  This
      is because by definition, we already have a reference to dest_keyring.
      
      This change is useful because we'll be making
      construct_get_dest_keyring() able to return an error code, and we don't
      want to have to handle that error here for no reason.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      a2d8737d
  25. 06 12月, 2017 1 次提交
  26. 05 12月, 2017 1 次提交
  27. 30 11月, 2017 1 次提交