Eric Lee / smarc-fsl-linux-kernel

15 Sep, 2011

1 commit

19 Jul, 2011

1 commit

  • f381c2722   integrity: move ima inode integrity data management ... Browse Code »

    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

  • 580689601   security: select correct default LSM_MMAP_MIN_ADDR on ARM. ... Browse Code »

    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

  • 7e70cb497   keys: add new key-type encrypted ... Browse Code »

    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
     
  • d00a1c72f   keys: add new trusted key-type ... Browse Code »

    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

  • eaf06b241   Restrict unprivileged access to kernel syslog ... Browse Code »

    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

  • b3a222e52   remove CONFIG_SECURITY_FILE_CAPABILITIES compile option ... Browse Code »

    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

  • 6e65f92ff   Config option to set a default LSM ... Browse Code »

    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

  • 3e1c2515a   security: remove root_plug ... Browse Code »

    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

  • 788084aba   Security/SELinux: seperate lsm specific mmap_min_addr ... Browse Code »

    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

  • 316253406   x86, intel_txt: Intel TXT boot support ... Browse Code »

    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

06 Feb, 2009

2 commits

  • cb5629b10   Merge branch 'master' into next ... Browse Code »

    Conflicts:
    fs/namei.c

    Manually merged per:

    diff --cc fs/namei.c
    index 734f2b5,bbc15c2..0000000
    --- a/fs/namei.c
    +++ b/fs/namei.c
    @@@ -860,9 -848,8 +849,10 @@@ static int __link_path_walk(const char
    nd->flags |= LOOKUP_CONTINUE;
    err = exec_permission_lite(inode);
    if (err == -EAGAIN)
    - err = vfs_permission(nd, MAY_EXEC);
    + err = inode_permission(nd->path.dentry->d_inode,
    + MAY_EXEC);
    + if (!err)
    + err = ima_path_check(&nd->path, MAY_EXEC);
    if (err)
    break;

    @@@ -1525,14 -1506,9 +1509,14 @@@ int may_open(struct path *path, int acc
    flag &= ~O_TRUNC;
    }

    - error = vfs_permission(nd, acc_mode);
    + error = inode_permission(inode, acc_mode);
    if (error)
    return error;
    +
    - error = ima_path_check(&nd->path,
    ++ error = ima_path_check(path,
    + acc_mode & (MAY_READ | MAY_WRITE | MAY_EXEC));
    + if (error)
    + return error;
    /*
    * An append-only file must be opened in append mode for writing.
    */

    Signed-off-by: James Morris

    James Morris
     
  • 3323eec92   integrity: IMA as an integrity service provider ... Browse Code »

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

    Mimi Zohar
     

01 Jan, 2009

1 commit

28 Aug, 2008

1 commit

  • da31894ed   securityfs: do not depend on CONFIG_SECURITY ... Browse Code »

    Add a new Kconfig option SECURITYFS which will build securityfs support
    but does not require CONFIG_SECURITY. The only current user of
    securityfs does not depend on CONFIG_SECURITY and there is no reason the
    full LSM needs to be built to build this fs.

    Signed-off-by: Eric Paris
    Signed-off-by: James Morris

    Eric Paris
     

25 Jul, 2008

1 commit

14 Jul, 2008

2 commits

18 Apr, 2008

1 commit

  • 5f46ce14b   security: enhance DEFAULT_MMAP_MIN_ADDR description ... Browse Code »

    Got burned by setting the proposed default of 65536
    across all Debian archs.

    Thus proposing to be more specific on which archs you may
    set this. Also propose a value for arm and friends that
    doesn't break sshd.

    Reword to mention working archs ia64 and ppc64 too.

    Signed-off-by: maximilian attems
    Cc: Martin Michlmayr
    Cc: Gordon Farquharson
    Acked-by: Eric Paris
    Signed-off-by: James Morris

    maximilian attems
     

06 Feb, 2008

2 commits

  • a5ecbcb8c   security: allow Kconfig to set default mmap_min_addr protection ... Browse Code »

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

    Signed-off-by: Eric Paris
    Signed-off-by: James Morris

    Eric Paris
     
  • e114e4737   Smack: Simplified Mandatory Access Control Kernel ... Browse Code »

    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: Casey Schaufler
    Cc: Joshua Brindle
    Cc: Paul Moore
    Cc: Stephen Smalley
    Cc: Chris Wright
    Cc: James Morris
    Cc: "Ahmed S. Darwish"
    Cc: Andrew G. Morgan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Casey Schaufler
     

30 Jan, 2008

1 commit

17 Oct, 2007

2 commits

  • b53767719   Implement file posix capabilities ... Browse Code »

    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: Serge E. Hallyn
    Cc: Stephen Smalley
    Cc: James Morris
    Cc: Chris Wright
    Cc: Andrew Morgan
    Signed-off-by: Andrew Morgan
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     
  • 20510f2f4   security: Convert LSM into a static interface ... Browse Code »

    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: James Morris
    Acked-by: Chris Wright
    Cc: Stephen Smalley
    Cc: "Serge E. Hallyn"
    Acked-by: Arjan van de Ven
    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    James Morris
     

30 Sep, 2006

1 commit

  • 3bc1fa8ae   [PATCH] LSM: remove BSD secure level security module ... Browse Code »

    This code has suffered from broken core design and lack of developer
    attention. Broken security modules are too dangerous to leave around. It
    is time to remove this one.

    Signed-off-by: Chris Wright
    Acked-by: Michael Halcrow
    Acked-by: Serge Hallyn
    Cc: Davi Arnaut
    Acked-by: Greg Kroah-Hartman
    Acked-by: James Morris
    Acked-by: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chris Wright
     

27 Jun, 2006

1 commit

04 Jan, 2006

1 commit

  • df71837d5   [LSM-IPSec]: Security association restriction. ... Browse Code »

    This patch series implements per packet access control via the
    extension of the Linux Security Modules (LSM) interface by hooks in
    the XFRM and pfkey subsystems that leverage IPSec security
    associations to label packets. Extensions to the SELinux LSM are
    included that leverage the patch for this purpose.

    This patch implements the changes necessary to the XFRM subsystem,
    pfkey interface, ipv4/ipv6, and xfrm_user interface to restrict a
    socket to use only authorized security associations (or no security
    association) to send/receive network packets.

    Patch purpose:

    The patch is designed to enable access control per packets based on
    the strongly authenticated IPSec security association. Such access
    controls augment the existing ones based on network interface and IP
    address. The former are very coarse-grained, and the latter can be
    spoofed. By using IPSec, the system can control access to remote
    hosts based on cryptographic keys generated using the IPSec mechanism.
    This enables access control on a per-machine basis or per-application
    if the remote machine is running the same mechanism and trusted to
    enforce the access control policy.

    Patch design approach:

    The overall approach is that policy (xfrm_policy) entries set by
    user-level programs (e.g., setkey for ipsec-tools) are extended with a
    security context that is used at policy selection time in the XFRM
    subsystem to restrict the sockets that can send/receive packets via
    security associations (xfrm_states) that are built from those
    policies.

    A presentation available at
    www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf
    from the SELinux symposium describes the overall approach.

    Patch implementation details:

    On output, the policy retrieved (via xfrm_policy_lookup or
    xfrm_sk_policy_lookup) must be authorized for the security context of
    the socket and the same security context is required for resultant
    security association (retrieved or negotiated via racoon in
    ipsec-tools). This is enforced in xfrm_state_find.

    On input, the policy retrieved must also be authorized for the socket
    (at __xfrm_policy_check), and the security context of the policy must
    also match the security association being used.

    The patch has virtually no impact on packets that do not use IPSec.
    The existing Netfilter (outgoing) and LSM rcv_skb hooks are used as
    before.

    Also, if IPSec is used without security contexts, the impact is
    minimal. The LSM must allow such policies to be selected for the
    combination of socket and remote machine, but subsequent IPSec
    processing proceeds as in the original case.

    Testing:

    The pfkey interface is tested using the ipsec-tools. ipsec-tools have
    been modified (a separate ipsec-tools patch is available for version
    0.5) that supports assignment of xfrm_policy entries and security
    associations with security contexts via setkey and the negotiation
    using the security contexts via racoon.

    The xfrm_user interface is tested via ad hoc programs that set
    security contexts. These programs are also available from me, and
    contain programs for setting, getting, and deleting policy for testing
    this interface. Testing of sa functions was done by tracing kernel
    behavior.

    Signed-off-by: Trent Jaeger
    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Trent Jaeger
     

23 Aug, 2005

1 commit

  • 2c40579bd   [PATCH] SECURITY must depend on SYSFS ... Browse Code »

    CONFIG_SECURITY=y and CONFIG_SYSFS=n results in the following compile
    error:

    ...
    LD vmlinux
    security/built-in.o: In function `securityfs_init':
    inode.c:(.init.text+0x1c2): undefined reference to `kernel_subsys'
    make: *** [vmlinux] Error 1

    Signed-off-by: Adrian Bunk
    Signed-off-by: Chris Wright

    Adrian Bunk
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds