1. 08 9月, 2016 1 次提交
  2. 20 8月, 2016 1 次提交
    • L
      Make the hardened user-copy code depend on having a hardened allocator · 6040e576
      Linus Torvalds 提交于
      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: Nkernel test robot <xiaolong.ye@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6040e576
  3. 27 7月, 2016 1 次提交
    • K
      mm: Hardened usercopy · f5509cc1
      Kees Cook 提交于
      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: NKees Cook <keescook@chromium.org>
      Tested-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Tested-by: NMichael Ellerman <mpe@ellerman.id.au>
      f5509cc1
  4. 21 4月, 2016 1 次提交
  5. 28 7月, 2015 1 次提交
  6. 16 4月, 2015 1 次提交
  7. 05 2月, 2014 1 次提交
  8. 11 5月, 2012 1 次提交
  9. 10 2月, 2012 1 次提交
  10. 15 9月, 2011 1 次提交
  11. 19 7月, 2011 1 次提交
    • M
      integrity: move ima inode integrity data management · f381c272
      Mimi Zohar 提交于
      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: NMimi Zohar <zohar@us.ibm.com>
      Acked-by: NSerge Hallyn <serge.hallyn@ubuntu.com>
      f381c272
  12. 22 3月, 2011 1 次提交
  13. 29 11月, 2010 2 次提交
    • M
      keys: add new key-type encrypted · 7e70cb49
      Mimi Zohar 提交于
      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: NMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: NDavid Safford <safford@watson.ibm.com>
      Reviewed-by: NRoberto Sassu <roberto.sassu@polito.it>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      7e70cb49
    • M
      keys: add new trusted key-type · d00a1c72
      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: NDavid Safford <safford@watson.ibm.com>
      Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      d00a1c72
  14. 12 11月, 2010 1 次提交
  15. 02 8月, 2010 1 次提交
  16. 24 11月, 2009 1 次提交
    • S
      remove CONFIG_SECURITY_FILE_CAPABILITIES compile option · b3a222e5
      Serge E. Hallyn 提交于
      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: NSerge E. Hallyn <serue@us.ibm.com>
      Acked-by: NAndrew G. Morgan" <morgan@kernel.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      b3a222e5
  17. 09 11月, 2009 1 次提交
  18. 20 10月, 2009 1 次提交
  19. 02 9月, 2009 1 次提交
  20. 19 8月, 2009 2 次提交
  21. 17 8月, 2009 1 次提交
    • E
      Security/SELinux: seperate lsm specific mmap_min_addr · 788084ab
      Eric Paris 提交于
      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: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      788084ab
  22. 15 8月, 2009 1 次提交
  23. 06 8月, 2009 1 次提交
    • E
      Security/SELinux: seperate lsm specific mmap_min_addr · a2551df7
      Eric Paris 提交于
      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: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      a2551df7
  24. 22 7月, 2009 1 次提交
    • J
      x86, intel_txt: Intel TXT boot support · 31625340
      Joseph Cihula 提交于
      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: NJoseph Cihula <joseph.cihula@intel.com>
      Signed-off-by: NShane Wang <shane.wang@intel.com>
      Signed-off-by: NGang Wei <gang.wei@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      31625340
  25. 04 6月, 2009 1 次提交
  26. 12 2月, 2009 1 次提交
  27. 06 2月, 2009 1 次提交
    • M
      integrity: IMA as an integrity service provider · 3323eec9
      Mimi Zohar 提交于
      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: NMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      3323eec9
  28. 01 1月, 2009 1 次提交
  29. 28 8月, 2008 1 次提交
  30. 25 7月, 2008 1 次提交
  31. 14 7月, 2008 2 次提交
  32. 18 4月, 2008 1 次提交
  33. 06 2月, 2008 2 次提交
    • E
      security: allow Kconfig to set default mmap_min_addr protection · a5ecbcb8
      Eric Paris 提交于
      Since it was decided that low memory protection from userspace couldn't
      be turned on by default add a Kconfig option to allow users/distros to
      set a default at compile time.  This value is still tunable after boot
      in /proc/sys/vm/mmap_min_addr
      
      Discussion:
      http://www.mail-archive.com/linux-security-module@vger.kernel.org/msg02543.htmlSigned-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      a5ecbcb8
    • C
      Smack: Simplified Mandatory Access Control Kernel · e114e473
      Casey Schaufler 提交于
      Smack is the Simplified Mandatory Access Control Kernel.
      
      Smack implements mandatory access control (MAC) using labels
      attached to tasks and data containers, including files, SVIPC,
      and other tasks. Smack is a kernel based scheme that requires
      an absolute minimum of application support and a very small
      amount of configuration data.
      
      Smack uses extended attributes and
      provides a set of general mount options, borrowing technics used
      elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides
      a pseudo-filesystem smackfs that is used for manipulation of
      system Smack attributes.
      
      The patch, patches for ls and sshd, a README, a startup script,
      and x86 binaries for ls and sshd are also available on
      
          http://www.schaufler-ca.com
      
      Development has been done using Fedora Core 7 in a virtual machine
      environment and on an old Sony laptop.
      
      Smack provides mandatory access controls based on the label attached
      to a task and the label attached to the object it is attempting to
      access. Smack labels are deliberately short (1-23 characters) text
      strings. Single character labels using special characters are reserved
      for system use. The only operation applied to Smack labels is equality
      comparison. No wildcards or expressions, regular or otherwise, are
      used. Smack labels are composed of printable characters and may not
      include "/".
      
      A file always gets the Smack label of the task that created it.
      
      Smack defines and uses these labels:
      
          "*" - pronounced "star"
          "_" - pronounced "floor"
          "^" - pronounced "hat"
          "?" - pronounced "huh"
      
      The access rules enforced by Smack are, in order:
      
      1. Any access requested by a task labeled "*" is denied.
      2. A read or execute access requested by a task labeled "^"
         is permitted.
      3. A read or execute access requested on an object labeled "_"
         is permitted.
      4. Any access requested on an object labeled "*" is permitted.
      5. Any access requested by a task on an object with the same
         label is permitted.
      6. Any access requested that is explicitly defined in the loaded
         rule set is permitted.
      7. Any other access is denied.
      
      Rules may be explicitly defined by writing subject,object,access
      triples to /smack/load.
      
      Smack rule sets can be easily defined that describe Bell&LaPadula
      sensitivity, Biba integrity, and a variety of interesting
      configurations. Smack rule sets can be modified on the fly to
      accommodate changes in the operating environment or even the time
      of day.
      
      Some practical use cases:
      
      Hierarchical levels. The less common of the two usual uses
      for MLS systems is to define hierarchical levels, often
      unclassified, confidential, secret, and so on. To set up smack
      to support this, these rules could be defined:
      
         C        Unclass rx
         S        C       rx
         S        Unclass rx
         TS       S       rx
         TS       C       rx
         TS       Unclass rx
      
      A TS process can read S, C, and Unclass data, but cannot write it.
      An S process can read C and Unclass. Note that specifying that
      TS can read S and S can read C does not imply TS can read C, it
      has to be explicitly stated.
      
      Non-hierarchical categories. This is the more common of the
      usual uses for an MLS system. Since the default rule is that a
      subject cannot access an object with a different label no
      access rules are required to implement compartmentalization.
      
      A case that the Bell & LaPadula policy does not allow is demonstrated
      with this Smack access rule:
      
      A case that Bell&LaPadula does not allow that Smack does:
      
          ESPN    ABC   r
          ABC     ESPN  r
      
      On my portable video device I have two applications, one that
      shows ABC programming and the other ESPN programming. ESPN wants
      to show me sport stories that show up as news, and ABC will
      only provide minimal information about a sports story if ESPN
      is covering it. Each side can look at the other's info, neither
      can change the other. Neither can see what FOX is up to, which
      is just as well all things considered.
      
      Another case that I especially like:
      
          SatData Guard   w
          Guard   Publish w
      
      A program running with the Guard label opens a UDP socket and
      accepts messages sent by a program running with a SatData label.
      The Guard program inspects the message to ensure it is wholesome
      and if it is sends it to a program running with the Publish label.
      This program then puts the information passed in an appropriate
      place. Note that the Guard program cannot write to a Publish
      file system object because file system semanitic require read as
      well as write.
      
      The four cases (categories, levels, mutual read, guardbox) here
      are all quite real, and problems I've been asked to solve over
      the years. The first two are easy to do with traditonal MLS systems
      while the last two you can't without invoking privilege, at least
      for a while.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      Cc: Joshua Brindle <method@manicmethod.com>
      Cc: Paul Moore <paul.moore@hp.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: James Morris <jmorris@namei.org>
      Cc: "Ahmed S. Darwish" <darwish.07@gmail.com>
      Cc: Andrew G. Morgan <morgan@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e114e473
  34. 30 1月, 2008 1 次提交
  35. 17 10月, 2007 2 次提交
    • S
      Implement file posix capabilities · b5376771
      Serge E. Hallyn 提交于
      Implement file posix capabilities.  This allows programs to be given a
      subset of root's powers regardless of who runs them, without having to use
      setuid and giving the binary all of root's powers.
      
      This version works with Kaigai Kohei's userspace tools, found at
      http://www.kaigai.gr.jp/index.php.  For more information on how to use this
      patch, Chris Friedhoff has posted a nice page at
      http://www.friedhoff.org/fscaps.html.
      
      Changelog:
      	Nov 27:
      	Incorporate fixes from Andrew Morton
      	(security-introduce-file-caps-tweaks and
      	security-introduce-file-caps-warning-fix)
      	Fix Kconfig dependency.
      	Fix change signaling behavior when file caps are not compiled in.
      
      	Nov 13:
      	Integrate comments from Alexey: Remove CONFIG_ ifdef from
      	capability.h, and use %zd for printing a size_t.
      
      	Nov 13:
      	Fix endianness warnings by sparse as suggested by Alexey
      	Dobriyan.
      
      	Nov 09:
      	Address warnings of unused variables at cap_bprm_set_security
      	when file capabilities are disabled, and simultaneously clean
      	up the code a little, by pulling the new code into a helper
      	function.
      
      	Nov 08:
      	For pointers to required userspace tools and how to use
      	them, see http://www.friedhoff.org/fscaps.html.
      
      	Nov 07:
      	Fix the calculation of the highest bit checked in
      	check_cap_sanity().
      
      	Nov 07:
      	Allow file caps to be enabled without CONFIG_SECURITY, since
      	capabilities are the default.
      	Hook cap_task_setscheduler when !CONFIG_SECURITY.
      	Move capable(TASK_KILL) to end of cap_task_kill to reduce
      	audit messages.
      
      	Nov 05:
      	Add secondary calls in selinux/hooks.c to task_setioprio and
      	task_setscheduler so that selinux and capabilities with file
      	cap support can be stacked.
      
      	Sep 05:
      	As Seth Arnold points out, uid checks are out of place
      	for capability code.
      
      	Sep 01:
      	Define task_setscheduler, task_setioprio, cap_task_kill, and
      	task_setnice to make sure a user cannot affect a process in which
      	they called a program with some fscaps.
      
      	One remaining question is the note under task_setscheduler: are we
      	ok with CAP_SYS_NICE being sufficient to confine a process to a
      	cpuset?
      
      	It is a semantic change, as without fsccaps, attach_task doesn't
      	allow CAP_SYS_NICE to override the uid equivalence check.  But since
      	it uses security_task_setscheduler, which elsewhere is used where
      	CAP_SYS_NICE can be used to override the uid equivalence check,
      	fixing it might be tough.
      
      	     task_setscheduler
      		 note: this also controls cpuset:attach_task.  Are we ok with
      		     CAP_SYS_NICE being used to confine to a cpuset?
      	     task_setioprio
      	     task_setnice
      		 sys_setpriority uses this (through set_one_prio) for another
      		 process.  Need same checks as setrlimit
      
      	Aug 21:
      	Updated secureexec implementation to reflect the fact that
      	euid and uid might be the same and nonzero, but the process
      	might still have elevated caps.
      
      	Aug 15:
      	Handle endianness of xattrs.
      	Enforce capability version match between kernel and disk.
      	Enforce that no bits beyond the known max capability are
      	set, else return -EPERM.
      	With this extra processing, it may be worth reconsidering
      	doing all the work at bprm_set_security rather than
      	d_instantiate.
      
      	Aug 10:
      	Always call getxattr at bprm_set_security, rather than
      	caching it at d_instantiate.
      
      [morgan@kernel.org: file-caps clean up for linux/capability.h]
      [bunk@kernel.org: unexport cap_inode_killpriv]
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: James Morris <jmorris@namei.org>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: Andrew Morgan <morgan@kernel.org>
      Signed-off-by: NAndrew Morgan <morgan@kernel.org>
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b5376771
    • J
      security: Convert LSM into a static interface · 20510f2f
      James Morris 提交于
      Convert LSM into a static interface, as the ability to unload a security
      module is not required by in-tree users and potentially complicates the
      overall security architecture.
      
      Needlessly exported LSM symbols have been unexported, to help reduce API
      abuse.
      
      Parameters for the capability and root_plug modules are now specified
      at boot.
      
      The SECURITY_FRAMEWORK_VERSION macro has also been removed.
      
      In a nutshell, there is no safe way to unload an LSM.  The modular interface
      is thus unecessary and broken infrastructure.  It is used only by out-of-tree
      modules, which are often binary-only, illegal, abusive of the API and
      dangerous, e.g.  silently re-vectoring SELinux.
      
      [akpm@linux-foundation.org: cleanups]
      [akpm@linux-foundation.org: USB Kconfig fix]
      [randy.dunlap@oracle.com: fix LSM kernel-doc]
      Signed-off-by: NJames Morris <jmorris@namei.org>
      Acked-by: NChris Wright <chrisw@sous-sol.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: "Serge E. Hallyn" <serue@us.ibm.com>
      Acked-by: NArjan van de Ven <arjan@infradead.org>
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20510f2f