24 Mar, 2018

1 commit

  • [ Upstream commit 22ec1a2aea73b9dfe340dff7945bd85af4cc6280 ]

    As done for /proc/kcore in

    commit df04abfd181a ("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: Michael Holzheu
    Fixes: f5509cc18daa ("mm: Hardened usercopy")
    Signed-off-by: Kees Cook
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Kees Cook
     

17 Jan, 2018

1 commit

  • commit a237f762681e2a394ca67f21df2feb2b76a3609b upstream.

    When the config option for PTI was added a reference to documentation was
    added as well. But the documentation did not exist at that point. The final
    documentation has a different file name.

    Fix it up to point to the proper file.

    Fixes: 385ce0ea ("x86/mm/pti: Add Kconfig")
    Signed-off-by: W. Trevor King
    Signed-off-by: Thomas Gleixner
    Cc: Dave Hansen
    Cc: linux-mm@kvack.org
    Cc: linux-security-module@vger.kernel.org
    Cc: James Morris
    Cc: "Serge E. Hallyn"
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/3009cc8ccbddcd897ec1e0cb6dda524929de0d14.1515799398.git.wking@tremily.us
    Signed-off-by: Greg Kroah-Hartman

    W. Trevor King
     

03 Jan, 2018

1 commit

  • commit 385ce0ea4c078517fa51c261882c4e72fba53005 upstream.

    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: Dave Hansen
    Signed-off-by: Thomas Gleixner
    Cc: Andy Lutomirski
    Cc: Boris Ostrovsky
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: David Laight
    Cc: Denys Vlasenko
    Cc: Eduardo Valentin
    Cc: Greg KH
    Cc: H. Peter Anvin
    Cc: Josh Poimboeuf
    Cc: Juergen Gross
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Will Deacon
    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: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Dave Hansen
     

13 Jul, 2017

1 commit

  • 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
    overhead.

    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.org
    Signed-off-by: Daniel Micay
    Signed-off-by: Kees Cook
    Signed-off-by: Arnd Bergmann
    Acked-by: Kees Cook
    Cc: Mark Rutland
    Cc: Daniel Axtens
    Cc: Rasmus Villemoes
    Cc: Andy Shevchenko
    Cc: Chris Metcalf
    Cc: Thomas Gleixner
    Cc: "H. Peter Anvin"
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daniel Micay
     

24 May, 2017

1 commit

  • 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
    flow.

    To keep the security changes isolated a new file is used to hold security
    related functionality.

    Signed-off-by: Daniel Jurgens
    Acked-by: Doug Ledford
    [PM: merge fixup in ib_verbs.h and uverbs_cmd.c]
    Signed-off-by: Paul Moore

    Daniel Jurgens
     

22 May, 2017

1 commit


15 May, 2017

1 commit


03 May, 2017

1 commit

  • Pull security subsystem updates from James Morris:
    "Highlights:

    IMA:
    - provide ">" and " of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (98 commits)
    tpm: Fix reference count to main device
    tpm_tis: convert to using locality callbacks
    tpm: fix handling of the TPM 2.0 event logs
    tpm_crb: remove a cruft constant
    keys: select CONFIG_CRYPTO when selecting DH / KDF
    apparmor: Make path_max parameter readonly
    apparmor: fix parameters so that the permission test is bypassed at boot
    apparmor: fix invalid reference to index variable of iterator line 836
    apparmor: use SHASH_DESC_ON_STACK
    security/apparmor/lsm.c: set debug messages
    apparmor: fix boolreturn.cocci warnings
    Smack: Use GFP_KERNEL for smk_netlbl_mls().
    smack: fix double free in smack_parse_opts_str()
    KEYS: add SP800-56A KDF support for DH
    KEYS: Keyring asymmetric key restrict method with chaining
    KEYS: Restrict asymmetric key linkage using a specific keychain
    KEYS: Add a lookup_restriction function for the asymmetric key type
    KEYS: Add KEYCTL_RESTRICT_KEYRING
    KEYS: Consistent ordering for __key_link_begin and restrict check
    KEYS: Add an optional lookup_restriction hook to key_type
    ...

    Linus Torvalds
     

27 Apr, 2017

1 commit


06 Mar, 2017

1 commit

  • Subsequent patches will add RO hardening to LSM hooks, however, SELinux
    still needs to be able to perform runtime disablement after init to handle
    architectures where init-time disablement via boot parameters is not feasible.

    Introduce a new kernel configuration parameter CONFIG_SECURITY_WRITABLE_HOOKS,
    and a helper macro __lsm_ro_after_init, to handle this case.

    Signed-off-by: James Morris
    Acked-by: Stephen Smalley
    Acked-by: Casey Schaufler
    Acked-by: Kees Cook

    James Morris
     

19 Jan, 2017

1 commit

  • 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
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

08 Sep, 2016

2 commits

  • Pull more hardened usercopyfixes from Kees Cook:

    - force check_object_size() to be inline too

    - move page-spanning check behind a CONFIG since it's triggering false
    positives

    [ Changed the page-spanning config option to depend on EXPERT in the
    merge. That way it still gets build testing, and you can enable it if
    you want to, but is never enabled for "normal" configurations ]

    * tag 'usercopy-v4.8-rc6-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
    usercopy: remove page-spanning test for now
    usercopy: force check_object_size() inline

    Linus Torvalds
     
  • A custom allocator without __GFP_COMP that copies to userspace has been
    found in vmw_execbuf_process[1], so this disables the page-span checker
    by placing it behind a CONFIG for future work where such things can be
    tracked down later.

    [1] https://bugzilla.redhat.com/show_bug.cgi?id=1373326

    Reported-by: Vinson Lee
    Fixes: f5509cc18daa ("mm: Hardened usercopy")
    Signed-off-by: Kees Cook

    Kees Cook
     

20 Aug, 2016

1 commit

  • 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: kernel test robot
    Cc: Kees Cook
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

27 Jul, 2016

1 commit

  • 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: Kees Cook
    Tested-by: Valdis Kletnieks
    Tested-by: Michael Ellerman

    Kees Cook
     

21 Apr, 2016

1 commit

  • This LSM enforces that kernel-loaded files (modules, firmware, etc)
    must all come from the same filesystem, with the expectation that
    such a filesystem is backed by a read-only device such as dm-verity
    or CDROM. This allows systems that have a verified and/or unchangeable
    filesystem to enforce module and firmware loading restrictions without
    needing to sign the files individually.

    Signed-off-by: Kees Cook
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Kees Cook
     

28 Jul, 2015

1 commit

  • Now that minor LSMs can cleanly stack with major LSMs, remove the unneeded
    config for Yama to be made to explicitly stack. Just selecting the main
    Yama CONFIG will allow it to work, regardless of the major LSM. Since
    distros using Yama are already forcing it to stack, this is effectively
    a no-op change.

    Additionally add MAINTAINERS entry.

    Signed-off-by: Kees Cook
    Signed-off-by: James Morris

    Kees Cook
     

16 Apr, 2015

1 commit

  • 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: Iulia Manda
    Reviewed-by: Josh Triplett
    Acked-by: Geert Uytterhoeven
    Tested-by: Paul E. McKenney
    Reviewed-by: Paul E. McKenney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Iulia Manda
     

05 Feb, 2014

1 commit


11 May, 2012

1 commit


10 Feb, 2012

1 commit

  • This adds the Yama Linux Security Module to collect DAC security
    improvements (specifically just ptrace restrictions for now) that have
    existed in various forms over the years and have been carried outside the
    mainline kernel by other Linux distributions like Openwall and grsecurity.

    Signed-off-by: Kees Cook
    Acked-by: John Johansen
    Signed-off-by: James Morris

    Kees Cook
     

15 Sep, 2011

1 commit


19 Jul, 2011

1 commit

  • Move the inode integrity data(iint) management up to the integrity directory
    in order to share the iint among the different integrity models.

    Changelog:
    - 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: Mimi Zohar
    Acked-by: Serge Hallyn

    Mimi Zohar
     

22 Mar, 2011

1 commit

  • The default for this is universally set to 64k, but the help says:

    For most ia64, ppc64 and x86 users with lots of address space
    a value of 65536 is reasonable and should cause no problems.
    On arm and other archs it should not be higher than 32768.

    The text is right, in that we are seeing selinux-enabled ARM targets
    that fail to launch /sbin/init because selinux blocks a memory map.
    So select the right value if we know we are building ARM.

    Signed-off-by: Paul Gortmaker
    Signed-off-by: James Morris

    Paul Gortmaker
     

29 Nov, 2010

2 commits

  • 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.

    Changelog:
    - 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: Mimi Zohar
    Signed-off-by: David Safford
    Reviewed-by: Roberto Sassu
    Signed-off-by: James Morris

    Mimi Zohar
     
  • 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.

    Changelog:
    - 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: David Safford
    Signed-off-by: Mimi Zohar
    Signed-off-by: James Morris

    Mimi Zohar
     

12 Nov, 2010

1 commit

  • The kernel syslog contains debugging information that is often useful
    during exploitation of other vulnerabilities, such as kernel heap
    addresses. Rather than futilely attempt to sanitize hundreds (or
    thousands) of printk statements and simultaneously cripple useful
    debugging functionality, it is far simpler to create an option that
    prevents unprivileged users from reading the syslog.

    This patch, loosely based on grsecurity's GRKERNSEC_DMESG, creates the
    dmesg_restrict sysctl. When set to "0", the default, no restrictions are
    enforced. When set to "1", only users with CAP_SYS_ADMIN can read the
    kernel syslog via dmesg(8) or other mechanisms.

    [akpm@linux-foundation.org: explain the config option in kernel.txt]
    Signed-off-by: Dan Rosenberg
    Acked-by: Ingo Molnar
    Acked-by: Eugene Teo
    Acked-by: Kees Cook
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dan Rosenberg
     

02 Aug, 2010

1 commit


24 Nov, 2009

1 commit

  • 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.

    Changelog:
    Nov 20: remove cap_limit_ptraced_target() as it's logic
    was ifndef'ed.

    Signed-off-by: Serge E. Hallyn
    Acked-by: Andrew G. Morgan"
    Signed-off-by: James Morris

    Serge E. Hallyn
     

09 Nov, 2009

1 commit

  • The LSM currently requires setting a kernel parameter at boot to select
    a specific LSM. This adds a config option that allows specifying a default
    LSM that is used unless overridden with the security= kernel parameter.
    If the the config option is not set the current behavior of first LSM
    to register is used.

    Signed-off-by: John Johansen
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    John Johansen
     

20 Oct, 2009

1 commit

  • Remove the root_plug example LSM code. It's unmaintained and
    increasingly broken in various ways.

    Made at the 2009 Kernel Summit in Tokyo!

    Acked-by: Greg Kroah-Hartman
    Signed-off-by: James Morris

    James Morris
     

02 Sep, 2009

2 commits


19 Aug, 2009

2 commits


17 Aug, 2009

1 commit

  • 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
    CONFIG_LSM_MMAP_MIN_ADDR.

    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: Eric Paris
    Signed-off-by: James Morris

    Eric Paris
     

15 Aug, 2009

1 commit


22 Jul, 2009

1 commit

  • 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
    properly.

    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: Joseph Cihula
    Signed-off-by: Shane Wang
    Signed-off-by: Gang Wei
    Signed-off-by: H. Peter Anvin

    Joseph Cihula
     

04 Jun, 2009

1 commit


12 Feb, 2009

1 commit