Skip to content
Snippets Groups Projects
  1. May 18, 2023
  2. May 08, 2023
  3. Apr 24, 2023
    • Eric Snowberg's avatar
      integrity: machine keyring CA configuration · 099f26f2
      Eric Snowberg authored
      
      Add machine keyring CA restriction options to control the type of
      keys that may be added to it. The motivation is separation of
      certificate signing from code signing keys. Subsquent work will
      limit certificates being loaded into the IMA keyring to code
      signing keys used for signature verification.
      
      When no restrictions are selected, all Machine Owner Keys (MOK) are added
      to the machine keyring.  When CONFIG_INTEGRITY_CA_MACHINE_KEYRING is
      selected, the CA bit must be true.  Also the key usage must contain
      keyCertSign, any other usage field may be set as well.
      
      When CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX is selected, the CA bit must
      be true. Also the key usage must contain keyCertSign and the
      digitialSignature usage may not be set.
      
      Signed-off-by: default avatarEric Snowberg <eric.snowberg@oracle.com>
      Acked-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Tested-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      099f26f2
  4. Apr 13, 2023
  5. Apr 12, 2023
  6. Apr 06, 2023
  7. Apr 05, 2023
  8. Apr 04, 2023
  9. Mar 30, 2023
  10. Mar 23, 2023
  11. Mar 21, 2023
    • David Howells's avatar
      keys: Do not cache key in task struct if key is requested from kernel thread · 47f9e4c9
      David Howells authored
      
      The key which gets cached in task structure from a kernel thread does not
      get invalidated even after expiry.  Due to which, a new key request from
      kernel thread will be served with the cached key if it's present in task
      struct irrespective of the key validity.  The change is to not cache key in
      task_struct when key requested from kernel thread so that kernel thread
      gets a valid key on every key request.
      
      The problem has been seen with the cifs module doing DNS lookups from a
      kernel thread and the results getting pinned by being attached to that
      kernel thread's cache - and thus not something that can be easily got rid
      of.  The cache would ordinarily be cleared by notify-resume, but kernel
      threads don't do that.
      
      This isn't seen with AFS because AFS is doing request_key() within the
      kernel half of a user thread - which will do notify-resume.
      
      Fixes: 7743c48e ("keys: Cache result of request_key*() temporarily in task_struct")
      Signed-off-by: default avatarBharath SM <bharathsm@microsoft.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      cc: Shyam Prasad N <nspmangalore@gmail.com>
      cc: Steve French <smfrench@gmail.com>
      cc: keyrings@vger.kernel.org
      cc: linux-cifs@vger.kernel.org
      cc: linux-fsdevel@vger.kernel.org
      Link: https://lore.kernel.org/r/CAGypqWw951d=zYRbdgNR4snUDvJhWL=q3=WOyh7HhSJupjz2vA@mail.gmail.com/
      47f9e4c9
  12. Mar 20, 2023
    • Paul Moore's avatar
      selinux: remove the runtime disable functionality · f22f9aaf
      Paul Moore authored
      
      After working with the larger SELinux-based distros for several
      years, we're finally at a place where we can disable the SELinux
      runtime disable functionality.  The existing kernel deprecation
      notice explains the functionality and why we want to remove it:
      
        The selinuxfs "disable" node allows SELinux to be disabled at
        runtime prior to a policy being loaded into the kernel.  If
        disabled via this mechanism, SELinux will remain disabled until
        the system is rebooted.
      
        The preferred method of disabling SELinux is via the "selinux=0"
        boot parameter, but the selinuxfs "disable" node was created to
        make it easier for systems with primitive bootloaders that did not
        allow for easy modification of the kernel command line.
        Unfortunately, allowing for SELinux to be disabled at runtime makes
        it difficult to secure the kernel's LSM hooks using the
        "__ro_after_init" feature.
      
      It is that last sentence, mentioning the '__ro_after_init' hardening,
      which is the real motivation for this change, and if you look at the
      diffstat you'll see that the impact of this patch reaches across all
      the different LSMs, helping prevent tampering at the LSM hook level.
      
      From a SELinux perspective, it is important to note that if you
      continue to disable SELinux via "/etc/selinux/config" it may appear
      that SELinux is disabled, but it is simply in an uninitialized state.
      If you load a policy with `load_policy -i`, you will see SELinux
      come alive just as if you had loaded the policy during early-boot.
      
      It is also worth noting that the "/sys/fs/selinux/disable" file is
      always writable now, regardless of the Kconfig settings, but writing
      to the file has no effect on the system, other than to display an
      error on the console if a non-zero/true value is written.
      
      Finally, in the several years where we have been working on
      deprecating this functionality, there has only been one instance of
      someone mentioning any user visible breakage.  In this particular
      case it was an individual's kernel test system, and the workaround
      documented in the deprecation notice ("selinux=0" on the kernel
      command line) resolved the issue without problem.
      
      Acked-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      f22f9aaf
    • Paul Moore's avatar
      selinux: remove the 'checkreqprot' functionality · a7e4676e
      Paul Moore authored
      
      We originally promised that the SELinux 'checkreqprot' functionality
      would be removed no sooner than June 2021, and now that it is March
      2023 it seems like it is a good time to do the final removal.  The
      deprecation notice in the kernel provides plenty of detail on why
      'checkreqprot' is not desirable, with the key point repeated below:
      
        This was a compatibility mechanism for legacy userspace and
        for the READ_IMPLIES_EXEC personality flag.  However, if set to
        1, it weakens security by allowing mappings to be made executable
        without authorization by policy.  The default value of checkreqprot
        at boot was changed starting in Linux v4.4 to 0 (i.e. check the
        actual protection), and Android and Linux distributions have been
        explicitly writing a "0" to /sys/fs/selinux/checkreqprot during
        initialization for some time.
      
      Along with the official deprecation notice, we have been discussing
      this on-list and directly with several of the larger SELinux-based
      distros and everyone is happy to see this feature finally removed.
      In an attempt to catch all of the smaller, and DIY, Linux systems
      we have been writing a deprecation notice URL into the kernel log,
      along with a growing ssleep() penalty, when admins enabled
      checkreqprot at runtime or via the kernel command line.  We have
      yet to have anyone come to us and raise an objection to the
      deprecation or planned removal.
      
      It is worth noting that while this patch removes the checkreqprot
      functionality, it leaves the user visible interfaces (kernel command
      line and selinuxfs file) intact, just inert.  This should help
      prevent breakages with existing userspace tools that correctly, but
      unnecessarily, disable checkreqprot at boot or runtime.  Admins
      that attempt to enable checkreqprot will be met with a removal
      message in the kernel log.
      
      Acked-by: default avatarStephen Smalley <stephen.smalley.work@gmail.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      a7e4676e
  13. Mar 18, 2023
  14. Mar 17, 2023
  15. Mar 15, 2023
    • Randy Dunlap's avatar
      IMA: allow/fix UML builds · 644f1741
      Randy Dunlap authored
      
      UML supports HAS_IOMEM since 0bbadafd (um: allow disabling
      NO_IOMEM).
      
      Current IMA build on UML fails on allmodconfig (with TCG_TPM=m):
      
      ld: security/integrity/ima/ima_queue.o: in function `ima_add_template_entry':
      ima_queue.c:(.text+0x2d9): undefined reference to `tpm_pcr_extend'
      ld: security/integrity/ima/ima_init.o: in function `ima_init':
      ima_init.c:(.init.text+0x43f): undefined reference to `tpm_default_chip'
      ld: security/integrity/ima/ima_crypto.o: in function `ima_calc_boot_aggregate_tfm':
      ima_crypto.c:(.text+0x1044): undefined reference to `tpm_pcr_read'
      ld: ima_crypto.c:(.text+0x10d8): undefined reference to `tpm_pcr_read'
      
      Modify the IMA Kconfig entry so that it selects TCG_TPM if HAS_IOMEM
      is set, regardless of the UML Kconfig setting.
      This updates TCG_TPM from =m to =y and fixes the linker errors.
      
      Fixes: f4a0391d ("ima: fix Kconfig dependencies")
      Cc: Stable <stable@vger.kernel.org> # v5.14+
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: linux-um@lists.infradead.org
      Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      644f1741
  16. Mar 14, 2023
  17. Mar 10, 2023
  18. Mar 08, 2023
    • Kamalesh Babulal's avatar
      device_cgroup: Fix typo in devcgroup_css_alloc description · f89f8e16
      Kamalesh Babulal authored
      
      Fix the stale cgroup.c path in the devcgroup_css_alloc() description.
      
      Signed-off-by: default avatarKamalesh Babulal <kamalesh.babulal@oracle.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      f89f8e16
    • Paul Moore's avatar
      lsm: fix a badly named parameter in security_get_getsecurity() · b3816cf8
      Paul Moore authored
      
      There is no good reason for why the "_buffer" parameter needs an
      underscore, get rid of it.
      
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      b3816cf8
    • Paul Moore's avatar
      1e2523d7
    • XU pengfei's avatar
      smack_lsm: remove unnecessary type casting · 502a29b0
      XU pengfei authored
      
      Remove unnecessary type casting.
      The type of inode variable is struct inode *, so no type casting required.
      
      Signed-off-by: default avatarXU pengfei <xupengfei@nfschina.com>
      Signed-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      502a29b0
    • Paul Moore's avatar
      selinux: uninline unlikely parts of avc_has_perm_noaudit() · f62ca0b6
      Paul Moore authored
      
      This is based on earlier patch posted to the list by Linus, his
      commit description read:
      
       "avc_has_perm_noaudit()is one of those hot functions that end up
        being used by almost all filesystem operations (through
        "avc_has_perm()") and it's intended to be cheap enough to inline.
      
        However, it turns out that the unlikely parts of it (where it
        doesn't find an existing avc node) need a fair amount of stack
        space for the automatic replacement node, so if it were to be
        inlined (at least clang does not) it would just use stack space
        unnecessarily.
      
        So split the unlikely part out of it, and mark that part noinline.
        That improves the actual likely part."
      
      The basic idea behind the patch was reasonable, but there were minor
      nits (double indenting, etc.) and the RCU read lock unlock/re-lock in
      avc_compute_av() began to look even more ugly.  This patch builds on
      Linus' first effort by cleaning things up a bit and removing the RCU
      unlock/lock dance in avc_compute_av().
      
      Removing the RCU lock dance in avc_compute_av() is safe as there are
      currently two callers of avc_compute_av(): avc_has_perm_noaudit() and
      avc_has_extended_perms().  The first caller in avc_has_perm_noaudit()
      does not require a RCU lock as there is no avc_node to protect so the
      RCU lock can be dropped before calling avc_compute_av().  The second
      caller, avc_has_extended_perms(), is similar in that there is no
      avc_node that requires RCU protection, but the code is simplified by
      holding the RCU look around the avc_compute_av() call, and given that
      we enter a RCU critical section in security_compute_av() (called from
      av_compute_av()) the impact will likely be unnoticeable.  It is also
      worth noting that avc_has_extended_perms() is only called from the
      SELinux ioctl() access control hook at the moment.
      
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      f62ca0b6
  19. Mar 06, 2023
Loading