1. 15 Jan, 2018 1 commit
    • Kees Cook's avatar
      usercopy: Allow strict enforcement of whitelists · 2d891fbc
      Kees Cook authored
      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
      Suggested-by: default avatarMatthew Garrett <mjg59@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
  2. 14 Jan, 2018 1 commit
  3. 03 Jan, 2018 1 commit
  4. 23 Dec, 2017 1 commit
    • Dave Hansen's avatar
      x86/mm/pti: Add Kconfig · 385ce0ea
      Dave Hansen authored
      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: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarThomas 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: default avatarIngo Molnar <mingo@kernel.org>
  5. 18 Dec, 2017 1 commit
    • Kees Cook's avatar
      /dev/mem: Add bounce buffer for copy-out · 22ec1a2a
      Kees Cook authored
      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
      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: default avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Fixes: f5509cc1 ("mm: Hardened usercopy")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. 12 Jul, 2017 1 commit
    • Daniel Micay's avatar
      include/linux/string.h: add the option of fortified string.h functions · 6974f0c4
      Daniel Micay authored
      This adds support for compiling with a rough equivalent to the glibc
      _FORTIFY_SOURCE=1 feature, providing compile-time and runtime buffer
      overflow checks for string.h functions when the compiler determines the
      size of the source or destination buffer at compile-time.  Unlike glibc,
      it covers buffer reads in addition to writes.
      GNU C __builtin_*_chk intrinsics are avoided because they would force a
      much more complex implementation.  They aren't designed to detect read
      overflows and offer no real benefit when using an implementation based
      on inline checks.  Inline checks don't add up to much code size and
      allow full use of the regular string intrinsics while avoiding the need
      for a bunch of _chk functions and per-arch assembly to avoid wrapper
      This detects various overflows at compile-time in various drivers and
      some non-x86 core kernel code.  There will likely be issues caught in
      regular use at runtime too.
      Future improvements left out of initial implementation for simplicity,
      as it's all quite optional and can be done incrementally:
      * Some of the fortified string functions (strncpy, strcat), don't yet
        place a limit on reads from the source based on __builtin_object_size of
        the source buffer.
      * Extending coverage to more string functions like strlcat.
      * It should be possible to optionally use __builtin_object_size(x, 1) for
        some functions (C strings) to detect intra-object overflows (like
        glibc's _FORTIFY_SOURCE=2), but for now this takes the conservative
        approach to avoid likely compatibility issues.
      * The compile-time checks should be made available via a separate config
        option which can be enabled by default (or always enabled) once enough
        time has passed to get the issues it catches fixed.
      Kees said:
       "This is great to have. While it was out-of-tree code, it would have
        blocked at least CVE-2016-3858 from being exploitable (improper size
        argument to strlcpy()). I've sent a number of fixes for
        out-of-bounds-reads that this detected upstream already"
      [arnd@arndb.de: x86: fix fortified memcpy]
        Link: http://lkml.kernel.org/r/20170627150047.660360-1-arnd@arndb.de
      [keescook@chromium.org: avoid panic() in favor of BUG()]
        Link: http://lkml.kernel.org/r/20170626235122.GA25261@beast
      [keescook@chromium.org: move from -mm, add ARCH_HAS_FORTIFY_SOURCE, tweak Kconfig help]
      Link: http://lkml.kernel.org/r/20170526095404.20439-1-danielmicay@gmail.com
      Link: http://lkml.kernel.org/r/1497903987-21002-8-git-send-email-keescook@chromium.orgSigned-off-by: default avatarDaniel Micay <danielmicay@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Daniel Axtens <dja@axtens.net>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  7. 23 May, 2017 1 commit
    • Daniel Jurgens's avatar
      IB/core: Enforce PKey security on QPs · d291f1a6
      Daniel Jurgens authored
      Add new LSM hooks to allocate and free security contexts and check for
      permission to access a PKey.
      Allocate and free a security context when creating and destroying a QP.
      This context is used for controlling access to PKeys.
      When a request is made to modify a QP that changes the port, PKey index,
      or alternate path, check that the QP has permission for the PKey in the
      PKey table index on the subnet prefix of the port. If the QP is shared
      make sure all handles to the QP also have access.
      Store which port and PKey index a QP is using. After the reset to init
      transition the user can modify the port, PKey index and alternate path
      independently. So port and PKey settings changes can be a merge of the
      previous settings and the new ones.
      In order to maintain access control if there are PKey table or subnet
      prefix change keep a list of all QPs are using each PKey index on
      each port. If a change occurs all QPs using that device and port must
      have access enforced for the new cache settings.
      These changes add a transaction to the QP modify process. Association
      with the old port and PKey index must be maintained if the modify fails,
      and must be removed if it succeeds. Association with the new port and
      PKey index must be established prior to the modify and removed if the
      modify fails.
      1. When a QP is modified to a particular Port, PKey index or alternate
         path insert that QP into the appropriate lists.
      2. Check permission to access the new settings.
      3. If step 2 grants access attempt to modify the QP.
      4a. If steps 2 and 3 succeed remove any prior associations.
      4b. If ether fails remove the new setting associations.
      If a PKey table or subnet prefix changes walk the list of QPs and
      check that they have permission. If not send the QP to the error state
      and raise a fatal error event. If it's a shared QP make sure all the
      QPs that share the real_qp have permission as well. If the QP that
      owns a security structure is denied access the security structure is
      marked as such and the QP is added to an error_list. Once the moving
      the QP to error is complete the security structure mark is cleared.
      Maintaining the lists correctly turns QP destroy into a transaction.
      The hardware driver for the device frees the ib_qp structure, so while
      the destroy is in progress the ib_qp pointer in the ib_qp_security
      struct is undefined. When the destroy process begins the ib_qp_security
      structure is marked as destroying. This prevents any action from being
      taken on the QP pointer. After the QP is destroyed successfully it
      could still listed on an error_list wait for it to be processed by that
      flow before cleaning up the structure.
      If the destroy fails the QPs port and PKey settings are reinserted into
      the appropriate lists, the destroying flag is cleared, and access control
      is enforced, in case there were any cache changes during the destroy
      To keep the security changes isolated a new file is used to hold security
      related functionality.
      Signed-off-by: default avatarDaniel Jurgens <danielj@mellanox.com>
      Acked-by: default avatarDoug Ledford <dledford@redhat.com>
      [PM: merge fixup in ib_verbs.h and uverbs_cmd.c]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
  8. 15 May, 2017 1 commit
  9. 26 Apr, 2017 1 commit
  10. 06 Mar, 2017 1 commit
  11. 19 Jan, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      Introduce STATIC_USERMODEHELPER to mediate call_usermodehelper() · 64e90a8a
      Greg Kroah-Hartman authored
      Some usermode helper applications are defined at kernel build time, while
      others can be changed at runtime.  To provide a sane way to filter these, add a
      new kernel option "STATIC_USERMODEHELPER".  This option routes all
      call_usermodehelper() calls through this binary, no matter what the caller
      wishes to have called.
      The new binary (by default set to /sbin/usermode-helper, but can be changed
      through the STATIC_USERMODEHELPER_PATH option) can properly filter the
      requested programs to be run by the kernel by looking at the first argument
      that is passed to it.  All other options should then be passed onto the proper
      program if so desired.
      To disable all call_usermodehelper() calls by the kernel, set
      STATIC_USERMODEHELPER_PATH to an empty string.
      Thanks to Neil Brown for the idea of this feature.
      Cc: NeilBrown <neilb@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. 07 Sep, 2016 1 commit
  13. 19 Aug, 2016 1 commit
    • Linus Torvalds's avatar
      Make the hardened user-copy code depend on having a hardened allocator · 6040e576
      Linus Torvalds authored
      The kernel test robot reported a usercopy failure in the new hardened
      sanity checks, due to a page-crossing copy of the FPU state into the
      task structure.
      This happened because the kernel test robot was testing with SLOB, which
      doesn't actually do the required book-keeping for slab allocations, and
      as a result the hardening code didn't realize that the task struct
      allocation was one single allocation - and the sanity checks fail.
      Since SLOB doesn't even claim to support hardening (and you really
      shouldn't use it), the straightforward solution is to just make the
      usercopy hardening code depend on the allocator supporting it.
      Reported-by: default avatarkernel test robot <xiaolong.ye@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  14. 26 Jul, 2016 1 commit
    • Kees Cook's avatar
      mm: Hardened usercopy · f5509cc1
      Kees Cook authored
      This is the start of porting PAX_USERCOPY into the mainline kernel. This
      is the first set of features, controlled by CONFIG_HARDENED_USERCOPY. The
      work is based on code by PaX Team and Brad Spengler, and an earlier port
      from Casey Schaufler. Additional non-slab page tests are from Rik van Riel.
      This patch contains the logic for validating several conditions when
      performing copy_to_user() and copy_from_user() on the kernel object
      being copied to/from:
      - address range doesn't wrap around
      - address range isn't NULL or zero-allocated (with a non-zero copy size)
      - if on the slab allocator:
        - object size must be less than or equal to copy size (when check is
          implemented in the allocator, which appear in subsequent patches)
      - otherwise, object must not span page allocations (excepting Reserved
        and CMA ranges)
      - if on the stack
        - object must not extend before/after the current process stack
        - object must be contained by a valid stack frame (when there is
          arch/build support for identifying stack frames)
      - object must not overlap with kernel text
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarValdis Kletnieks <valdis.kletnieks@vt.edu>
      Tested-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  15. 21 Apr, 2016 1 commit
  16. 28 Jul, 2015 1 commit
  17. 15 Apr, 2015 1 commit
    • Iulia Manda's avatar
      kernel: conditionally support non-root users, groups and capabilities · 2813893f
      Iulia Manda authored
      There are a lot of embedded systems that run most or all of their
      functionality in init, running as root:root.  For these systems,
      supporting multiple users is not necessary.
      This patch adds a new symbol, CONFIG_MULTIUSER, that makes support for
      non-root users, non-root groups, and capabilities optional.  It is enabled
      under CONFIG_EXPERT menu.
      When this symbol is not defined, UID and GID are zero in any possible case
      and processes always have all capabilities.
      The following syscalls are compiled out: setuid, setregid, setgid,
      setreuid, setresuid, getresuid, setresgid, getresgid, setgroups,
      getgroups, setfsuid, setfsgid, capget, capset.
      Also, groups.c is compiled out completely.
      In kernel/capability.c, capable function was moved in order to avoid
      adding two ifdef blocks.
      This change saves about 25 KB on a defconfig build.  The most minimal
      kernels have total text sizes in the high hundreds of kB rather than
      low MB.  (The 25k goes down a bit with allnoconfig, but not that much.
      The kernel was booted in Qemu.  All the common functionalities work.
      Adding users/groups is not possible, failing with -ENOSYS.
      Bloat-o-meter output:
      add/remove: 7/87 grow/shrink: 19/397 up/down: 1675/-26325 (-24650)
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarIulia Manda <iulia.manda21@gmail.com>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  18. 05 Feb, 2014 1 commit
  19. 11 May, 2012 1 commit
  20. 09 Feb, 2012 1 commit
  21. 14 Sep, 2011 1 commit
  22. 18 Jul, 2011 1 commit
    • Mimi Zohar's avatar
      integrity: move ima inode integrity data management · f381c272
      Mimi Zohar authored
      Move the inode integrity data(iint) management up to the integrity directory
      in order to share the iint among the different integrity models.
      - don't define MAX_DIGEST_SIZE
      - rename several globally visible 'ima_' prefixed functions, structs,
        locks, etc to 'integrity_'
      - replace '20' with SHA1_DIGEST_SIZE
      - reflect location change in appropriate Kconfig and Makefiles
      - remove unnecessary initialization of iint_initialized to 0
      - rebased on current ima_iint.c
      - define integrity_iint_store/lock as static
      There should be no other functional changes.
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@ubuntu.com>
  23. 21 Mar, 2011 1 commit
  24. 28 Nov, 2010 2 commits
    • Mimi Zohar's avatar
      keys: add new key-type encrypted · 7e70cb49
      Mimi Zohar authored
      Define a new kernel key-type called 'encrypted'. Encrypted keys are kernel
      generated random numbers, which are encrypted/decrypted with a 'trusted'
      symmetric key. Encrypted keys are created/encrypted/decrypted in the kernel.
      Userspace only ever sees/stores encrypted blobs.
      - bug fix: replaced master-key rcu based locking with semaphore
        (reported by David Howells)
      - Removed memset of crypto_shash_digest() digest output
      - Replaced verification of 'key-type:key-desc' using strcspn(), with
        one based on string constants.
      - Moved documentation to Documentation/keys-trusted-encrypted.txt
      - Replace hash with shash (based on comments by David Howells)
      - Make lengths/counts size_t where possible (based on comments by David Howells)
        Could not convert most lengths, as crypto expects 'unsigned int'
        (size_t: on 32 bit is defined as unsigned int, but on 64 bit is unsigned long)
      - Add 'const' where possible (based on comments by David Howells)
      - allocate derived_buf dynamically to support arbitrary length master key
        (fixed by Roberto Sassu)
      - wait until late_initcall for crypto libraries to be registered
      - cleanup security/Kconfig
      - Add missing 'update' keyword (reported/fixed by Roberto Sassu)
      - Free epayload on failure to create key (reported/fixed by Roberto Sassu)
      - Increase the data size limit (requested by Roberto Sassu)
      - Crypto return codes are always 0 on success and negative on failure,
        remove unnecessary tests.
      - Replaced kzalloc() with kmalloc()
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: default avatarDavid Safford <safford@watson.ibm.com>
      Reviewed-by: default avatarRoberto Sassu <roberto.sassu@polito.it>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    • Mimi Zohar's avatar
      keys: add new trusted key-type · d00a1c72
      Mimi Zohar authored
      Define a new kernel key-type called 'trusted'.  Trusted keys are random
      number symmetric keys, generated and RSA-sealed by the TPM.  The TPM
      only unseals the keys, if the boot PCRs and other criteria match.
      Userspace can only ever see encrypted blobs.
      Based on suggestions by Jason Gunthorpe, several new options have been
      added to support additional usages.
      The new options are:
      migratable=  designates that the key may/may not ever be updated
                   (resealed under a new key, new pcrinfo or new auth.)
      pcrlock=n    extends the designated PCR 'n' with a random value,
                   so that a key sealed to that PCR may not be unsealed
                   again until after a reboot.
      keyhandle=   specifies the sealing/unsealing key handle.
      keyauth=     specifies the sealing/unsealing key auth.
      blobauth=    specifies the sealed data auth.
      Implementation of a kernel reserved locality for trusted keys will be
      investigated for a possible future extension.
      - Updated and added examples to Documentation/keys-trusted-encrypted.txt
      - Moved generic TPM constants to include/linux/tpm_command.h
        (David Howell's suggestion.)
      - trusted_defined.c: replaced kzalloc with kmalloc, added pcrlock failure
        error handling, added const qualifiers where appropriate.
      - moved to late_initcall
      - updated from hash to shash (suggestion by David Howells)
      - reduced worst stack usage (tpm_seal) from 530 to 312 bytes
      - moved documentation to Documentation directory (suggestion by David Howells)
      - all the other code cleanups suggested by David Howells
      - Add pcrlock CAP_SYS_ADMIN dependency (based on comment by Jason Gunthorpe)
      - New options: migratable, pcrlock, keyhandle, keyauth, blobauth (based on
        discussions with Jason Gunthorpe)
      - Free payload on failure to create key(reported/fixed by Roberto Sassu)
      - Updated Kconfig and other descriptions (based on Serge Hallyn's suggestion)
      - Replaced kzalloc() with kmalloc() (reported by Serge Hallyn)
      Signed-off-by: default avatarDavid Safford <safford@watson.ibm.com>
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  25. 12 Nov, 2010 1 commit
  26. 02 Aug, 2010 1 commit
  27. 24 Nov, 2009 1 commit
    • Serge E. Hallyn's avatar
      remove CONFIG_SECURITY_FILE_CAPABILITIES compile option · b3a222e5
      Serge E. Hallyn authored
      As far as I know, all distros currently ship kernels with default
      CONFIG_SECURITY_FILE_CAPABILITIES=y.  Since having the option on
      leaves a 'no_file_caps' option to boot without file capabilities,
      the main reason to keep the option is that turning it off saves
      you (on my s390x partition) 5k.  In particular, vmlinux sizes
      came to:
      without patch fscaps=n:		 	53598392
      without patch fscaps=y:		 	53603406
      with this patch applied:		53603342
      with the security-next tree.
      Against this we must weigh the fact that there is no simple way for
      userspace to figure out whether file capabilities are supported,
      while things like per-process securebits, capability bounding
      sets, and adding bits to pI if CAP_SETPCAP is in pE are not supported
      with SECURITY_FILE_CAPABILITIES=n, leaving a bit of a problem for
      applications wanting to know whether they can use them and/or why
      something failed.
      It also adds another subtly different set of semantics which we must
      maintain at the risk of severe security regressions.
      So this patch removes the SECURITY_FILE_CAPABILITIES compile
      option.  It drops the kernel size by about 50k over the stock
      SECURITY_FILE_CAPABILITIES=y kernel, by removing the
      cap_limit_ptraced_target() function.
      	Nov 20: remove cap_limit_ptraced_target() as it's logic
      		was ifndef'ed.
      Signed-off-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Acked-by: default avatarAndrew G. Morgan" <morgan@kernel.org>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  28. 08 Nov, 2009 1 commit
  29. 20 Oct, 2009 1 commit
  30. 02 Sep, 2009 1 commit
  31. 18 Aug, 2009 2 commits
  32. 17 Aug, 2009 1 commit
    • Eric Paris's avatar
      Security/SELinux: seperate lsm specific mmap_min_addr · 788084ab
      Eric Paris authored
      Currently SELinux enforcement of controls on the ability to map low memory
      is determined by the mmap_min_addr tunable.  This patch causes SELinux to
      ignore the tunable and instead use a seperate Kconfig option specific to how
      much space the LSM should protect.
      The tunable will now only control the need for CAP_SYS_RAWIO and SELinux
      permissions will always protect the amount of low memory designated by
      This allows users who need to disable the mmap_min_addr controls (usual reason
      being they run WINE as a non-root user) to do so and still have SELinux
      controls preventing confined domains (like a web server) from being able to
      map some area of low memory.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  33. 14 Aug, 2009 1 commit
  34. 05 Aug, 2009 1 commit
    • Eric Paris's avatar
      Security/SELinux: seperate lsm specific mmap_min_addr · a2551df7
      Eric Paris authored
      Currently SELinux enforcement of controls on the ability to map low memory
      is determined by the mmap_min_addr tunable.  This patch causes SELinux to
      ignore the tunable and instead use a seperate Kconfig option specific to how
      much space the LSM should protect.
      The tunable will now only control the need for CAP_SYS_RAWIO and SELinux
      permissions will always protect the amount of low memory designated by
      This allows users who need to disable the mmap_min_addr controls (usual reason
      being they run WINE as a non-root user) to do so and still have SELinux
      controls preventing confined domains (like a web server) from being able to
      map some area of low memory.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  35. 21 Jul, 2009 1 commit
    • Joseph Cihula's avatar
      x86, intel_txt: Intel TXT boot support · 31625340
      Joseph Cihula authored
      This patch adds kernel configuration and boot support for Intel Trusted
      Execution Technology (Intel TXT).
      Intel's technology for safer computing, Intel Trusted Execution
      Technology (Intel TXT), defines platform-level enhancements that
      provide the building blocks for creating trusted platforms.
      Intel TXT was formerly known by the code name LaGrande Technology (LT).
      Intel TXT in Brief:
      o  Provides dynamic root of trust for measurement (DRTM)
      o  Data protection in case of improper shutdown
      o  Measurement and verification of launched environment
      Intel TXT is part of the vPro(TM) brand and is also available some
      non-vPro systems.  It is currently available on desktop systems based on
      the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell Optiplex 755, HP
      dc7800, etc.) and mobile systems based on the GM45, PM45, and GS45
      Express chipsets.
      For more information, see http://www.intel.com/technology/security/.
      This site also has a link to the Intel TXT MLE Developers Manual, which
      has been updated for the new released platforms.
      A much more complete description of how these patches support TXT, how to
      configure a system for it, etc. is in the Documentation/intel_txt.txt file
      in this patch.
      This patch provides the TXT support routines for complete functionality,
      documentation for TXT support and for the changes to the boot_params structure,
      and boot detection of a TXT launch.  Attempts to shutdown (reboot, Sx) the system
      will result in platform resets; subsequent patches will support these shutdown modes
       Documentation/intel_txt.txt      |  210 +++++++++++++++++++++
       Documentation/x86/zero-page.txt  |    1
       arch/x86/include/asm/bootparam.h |    3
       arch/x86/include/asm/fixmap.h    |    3
       arch/x86/include/asm/tboot.h     |  197 ++++++++++++++++++++
       arch/x86/kernel/Makefile         |    1
       arch/x86/kernel/setup.c          |    4
       arch/x86/kernel/tboot.c          |  379 +++++++++++++++++++++++++++++++++++++++
       security/Kconfig                 |   30 +++
       9 files changed, 827 insertions(+), 1 deletion(-)
      Signed-off-by: default avatarJoseph Cihula <joseph.cihula@intel.com>
      Signed-off-by: default avatarShane Wang <shane.wang@intel.com>
      Signed-off-by: default avatarGang Wei <gang.wei@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
  36. 04 Jun, 2009 1 commit
  37. 12 Feb, 2009 1 commit
  38. 05 Feb, 2009 1 commit
    • Mimi Zohar's avatar
      integrity: IMA as an integrity service provider · 3323eec9
      Mimi Zohar authored
      IMA provides hardware (TPM) based measurement and attestation for
      file measurements. As the Trusted Computing (TPM) model requires,
      IMA measures all files before they are accessed in any way (on the
      integrity_bprm_check, integrity_path_check and integrity_file_mmap
      hooks), and commits the measurements to the TPM. Once added to the
      TPM, measurements can not be removed.
      In addition, IMA maintains a list of these file measurements, which
      can be used to validate the aggregate value stored in the TPM.  The
      TPM can sign these measurements, and thus the system can prove, to
      itself and to a third party, the system's integrity in a way that
      cannot be circumvented by malicious or compromised software.
      - alloc ima_template_entry before calling ima_store_template()
      - log ima_add_boot_aggregate() failure
      - removed unused IMA_TEMPLATE_NAME_LEN
      - replaced hard coded string length with #define name
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>