15 Sep, 2011

1 commit

  • The posix xattr acls are 'system' prefixed, which normally would not
    affect security.evm. An interesting side affect of writing posix xattr
    acls is their modifying of the i_mode, which is included in security.evm.

    This patch updates security.evm when posix xattr acls are written.

    Signed-off-by: Mimi Zohar

    Mimi Zohar
     

19 Jul, 2011

3 commits

  • EVM protects a file's security extended attributes(xattrs) against integrity
    attacks. This patchset provides the framework and an initial method. The
    initial method maintains an HMAC-sha1 value across the security extended
    attributes, storing the HMAC value as the extended attribute 'security.evm'.
    Other methods of validating the integrity of a file's metadata will be posted
    separately (eg. EVM-digital-signatures).

    While this patchset does authenticate the security xattrs, and
    cryptographically binds them to the inode, coming extensions will bind other
    directory and inode metadata for more complete protection. To help simplify
    the review and upstreaming process, each extension will be posted separately
    (eg. IMA-appraisal, IMA-appraisal-directory). For a general overview of the
    proposed Linux integrity subsystem, refer to Dave Safford's whitepaper:
    http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf.

    EVM depends on the Kernel Key Retention System to provide it with a
    trusted/encrypted key for the HMAC-sha1 operation. The key is loaded onto the
    root's keyring using keyctl. Until EVM receives notification that the key has
    been successfully loaded onto the keyring (echo 1 > /evm), EVM can
    not create or validate the 'security.evm' xattr, but returns INTEGRITY_UNKNOWN.
    Loading the key and signaling EVM should be done as early as possible. Normally
    this is done in the initramfs, which has already been measured as part of the
    trusted boot. For more information on creating and loading existing
    trusted/encrypted keys, refer to Documentation/keys-trusted-encrypted.txt. A
    sample dracut patch, which loads the trusted/encrypted key and enables EVM, is
    available from http://linux-ima.sourceforge.net/#EVM.

    Based on the LSMs enabled, the set of EVM protected security xattrs is defined
    at compile. EVM adds the following three calls to the existing security hooks:
    evm_inode_setxattr(), evm_inode_post_setxattr(), and evm_inode_removexattr. To
    initialize and update the 'security.evm' extended attribute, EVM defines three
    calls: evm_inode_post_init(), evm_inode_post_setattr() and
    evm_inode_post_removexattr() hooks. To verify the integrity of a security
    xattr, EVM exports evm_verifyxattr().

    Changelog v7:
    - Fixed URL in EVM ABI documentation

    Changelog v6: (based on Serge Hallyn's review)
    - fix URL in patch description
    - remove evm_hmac_size definition
    - use SHA1_DIGEST_SIZE (removed both MAX_DIGEST_SIZE and evm_hmac_size)
    - moved linux include before other includes
    - test for crypto_hash_setkey failure
    - fail earlier for invalid key
    - clear entire encrypted key, even on failure
    - check xattr name length before comparing xattr names

    Changelog:
    - locking based on i_mutex, remove evm_mutex
    - using trusted/encrypted keys for storing the EVM key used in the HMAC-sha1
    operation.
    - replaced crypto hash with shash (Dmitry Kasatkin)
    - support for additional methods of verifying the security xattrs
    (Dmitry Kasatkin)
    - iint not allocated for all regular files, but only for those appraised
    - Use cap_sys_admin in lieu of cap_mac_admin
    - Use __vfs_setxattr_noperm(), without permission checks, from EVM

    Signed-off-by: Mimi Zohar
    Acked-by: Serge Hallyn

    Mimi Zohar
     
  • vfs_getxattr_alloc() and vfs_xattr_cmp() are two new kernel xattr helper
    functions. vfs_getxattr_alloc() first allocates memory for the requested
    xattr and then retrieves it. vfs_xattr_cmp() compares a given value with
    the contents of an extended attribute.

    Signed-off-by: Mimi Zohar
    Acked-by: Serge Hallyn

    Mimi Zohar
     
  • This patch changes the security_inode_init_security API by adding a
    filesystem specific callback to write security extended attributes.
    This change is in preparation for supporting the initialization of
    multiple LSM xattrs and the EVM xattr. Initially the callback function
    walks an array of xattrs, writing each xattr separately, but could be
    optimized to write multiple xattrs at once.

    For existing security_inode_init_security() calls, which have not yet
    been converted to use the new callback function, such as those in
    reiserfs and ocfs2, this patch defines security_old_inode_init_security().

    Signed-off-by: Mimi Zohar

    Mimi Zohar
     

25 May, 2011

1 commit

  • af4f136056c9 ("security: move LSM xattrnames to xattr.h") moved the
    XATTR_CAPS_SUFFIX define from capability.h to xattr.h. This makes sense
    except it was previously exports to userspace but xattr.h does not export
    it to userspace. This patch exports these headers to userspace to fix the
    ABI regression.

    There is some slight possibility that this will cause problems in other
    applications which used these #defines differently (wrongly) and I could
    JUST export the capabilities xattr name that we broke. Does anyonehave an
    idea how exposing these headers could cause a problem?

    Below is what is being exposed to userspace, included here since it isn't
    clear exactly what is going to be made available from the patch.

    /* Namespaces */
    #define XATTR_OS2_PREFIX "os2."
    #define XATTR_OS2_PREFIX_LEN (sizeof (XATTR_OS2_PREFIX) - 1)

    #define XATTR_SECURITY_PREFIX "security."
    #define XATTR_SECURITY_PREFIX_LEN (sizeof (XATTR_SECURITY_PREFIX) - 1)

    #define XATTR_SYSTEM_PREFIX "system."
    #define XATTR_SYSTEM_PREFIX_LEN (sizeof (XATTR_SYSTEM_PREFIX) - 1)

    #define XATTR_TRUSTED_PREFIX "trusted."
    #define XATTR_TRUSTED_PREFIX_LEN (sizeof (XATTR_TRUSTED_PREFIX) - 1)

    #define XATTR_USER_PREFIX "user."
    #define XATTR_USER_PREFIX_LEN (sizeof (XATTR_USER_PREFIX) - 1)

    /* Security namespace */
    #define XATTR_SELINUX_SUFFIX "selinux"
    #define XATTR_NAME_SELINUX XATTR_SECURITY_PREFIX XATTR_SELINUX_SUFFIX

    #define XATTR_SMACK_SUFFIX "SMACK64"
    #define XATTR_SMACK_IPIN "SMACK64IPIN"
    #define XATTR_SMACK_IPOUT "SMACK64IPOUT"
    #define XATTR_NAME_SMACK XATTR_SECURITY_PREFIX XATTR_SMACK_SUFFIX
    #define XATTR_NAME_SMACKIPIN XATTR_SECURITY_PREFIX XATTR_SMACK_IPIN
    #define XATTR_NAME_SMACKIPOUT XATTR_SECURITY_PREFIX XATTR_SMACK_IPOUT

    #define XATTR_CAPS_SUFFIX "capability"
    #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX

    Reported-by: Ozan Çaglayan
    Signed-off-by: Eric Paris
    Cc: Mimi Zohar
    Cc: Serge Hallyn
    Cc: James Morris
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Paris
     

18 Jan, 2011

1 commit

  • In the embedded world there are often situations
    where libraries are updated from a variety of sources,
    for a variety of reasons, and with any number of
    security characteristics. These differences
    might include privilege required for a given library
    provided interface to function properly, as occurs
    from time to time in graphics libraries. There are
    also cases where it is important to limit use of
    libraries based on the provider of the library and
    the security aware application may make choices
    based on that criteria.

    These issues are addressed by providing an additional
    Smack label that may optionally be assigned to an object,
    the SMACK64MMAP attribute. An mmap operation is allowed
    if there is no such attribute.

    If there is a SMACK64MMAP attribute the mmap is permitted
    only if a subject with that label has all of the access
    permitted a subject with the current task label.

    Security aware applications may from time to time
    wish to reduce their "privilege" to avoid accidental use
    of privilege. One case where this arises is the
    environment in which multiple sources provide libraries
    to perform the same functions. An application may know
    that it should eschew services made available from a
    particular vendor, or of a particular version.

    In support of this a secondary list of Smack rules has
    been added that is local to the task. This list is
    consulted only in the case where the global list has
    approved access. It can only further restrict access.
    Unlike the global last, if no entry is found on the
    local list access is granted. An application can add
    entries to its own list by writing to /smack/load-self.

    The changes appear large as they involve refactoring
    the list handling to accomodate there being more
    than one rule list.

    Signed-off-by: Casey Schaufler

    Casey Schaufler
     

08 Dec, 2010

1 commit

  • In a situation where Smack access rules allow processes
    with multiple labels to write to a directory it is easy
    to get into a situation where the directory gets cluttered
    with files that the owner can't deal with because while
    they could be written to the directory a process at the
    label of the directory can't write them. This is generally
    the desired behavior, but when it isn't it is a real
    issue.

    This patch introduces a new attribute SMACK64TRANSMUTE that
    instructs Smack to create the file with the label of the directory
    under certain circumstances.

    A new access mode, "t" for transmute, is made available to
    Smack access rules, which are expanded from "rwxa" to "rwxat".
    If a file is created in a directory marked as transmutable
    and if access was granted to perform the operation by a rule
    that included the transmute mode, then the file gets the
    Smack label of the directory instead of the Smack label of the
    creating process.

    Note that this is equivalent to creating an empty file at the
    label of the directory and then having the other process write
    to it. The transmute scheme requires that both the access rule
    allows transmutation and that the directory be explicitly marked.

    Signed-off-by: Jarkko Sakkinen
    Signed-off-by: Casey Schaufler

    Jarkko Sakkinen
     

02 Dec, 2010

1 commit

  • SMACK64EXEC. It defines label that is used while task is
    running.

    Exception: in smack_task_wait() child task is checked
    for write access to parent task using label inherited
    from the task that forked it.

    Fixed issues from previous submit:
    - SMACK64EXEC was not read when SMACK64 was not set.
    - inode security blob was not updated after setting
    SMACK64EXEC
    - inode security blob was not updated when removing
    SMACK64EXEC

    Casey Schaufler
     

02 Aug, 2010

1 commit


22 May, 2010

1 commit

  • The entries in xattr handler table should be immutable (ie const)
    like other operation tables.

    Later patches convert common filesystems. Uncoverted filesystems
    will still work, but will generate a compiler warning.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: Al Viro

    Stephen Hemminger
     

17 Dec, 2009

1 commit

  • Add a flags argument to struct xattr_handler and pass it to all xattr
    handler methods. This allows using the same methods for multiple
    handlers, e.g. for the ACL methods which perform exactly the same action
    for the access and default ACLs, just using a different underlying
    attribute. With a little more groundwork it'll also allow sharing the
    methods for the regular user/trusted/secure handlers in extN, ocfs2 and
    jffs2 like it's already done for xfs in this patch.

    Also change the inode argument to the handlers to a dentry to allow
    using the handlers mechnism for filesystems that require it later,
    e.g. cifs.

    [with GFS2 bits updated by Steven Whitehouse ]

    Signed-off-by: Christoph Hellwig
    Reviewed-by: James Morris
    Acked-by: Joel Becker
    Signed-off-by: Al Viro

    Christoph Hellwig
     

10 Sep, 2009

1 commit


29 Apr, 2008

1 commit


06 Feb, 2008

1 commit

  • This patch modifies the interface to inode_getsecurity to have the function
    return a buffer containing the security blob and its length via parameters
    instead of relying on the calling function to give it an appropriately sized
    buffer.

    Security blobs obtained with this function should be freed using the
    release_secctx LSM hook. This alleviates the problem of the caller having to
    guess a length and preallocate a buffer for this function allowing it to be
    used elsewhere for Labeled NFS.

    The patch also removed the unused err parameter. The conversion is similar to
    the one performed by Al Viro for the security_getprocattr hook.

    Signed-off-by: David P. Quigley
    Cc: Stephen Smalley
    Cc: Chris Wright
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Cc: Casey Schaufler
    Cc: Al Viro
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David P. Quigley
     

12 Feb, 2007

1 commit


10 Oct, 2006

1 commit

  • This patch moves code out of fs/xattr.c:listxattr into a new function -
    vfs_listxattr. The code for vfs_listxattr was originally submitted by Bill
    Nottingham to Unionfs.

    Sorry about that. The reason for this submission is to make the
    listxattr code in fs/xattr.c a little cleaner (as well as to clean up
    some code in Unionfs.)

    Currently, Unionfs has vfs_listxattr defined in its code. I think
    that's very ugly, and I'd like to see it (re)moved. The logical place
    to put it, is along side of all the other vfs_*xattr functions.

    Overall, I think this patch is benefitial for both kernel.org kernel and
    Unionfs.

    Signed-off-by: Josef "Jeff" Sipek
    Acked-by: Al Viro
    Signed-off-by: Linus Torvalds

    Bill Nottingham
     

11 Jan, 2006

2 commits

  • )

    From: Christoph Hellwig

    The xattr code has rather complex permission checks because the rules are very
    different for different attribute namespaces. This patch moves as much as we
    can into the generic code. Currently all the major disk based filesystems
    duplicate these checks, while many minor filesystems or network filesystems
    lack some or all of them.

    To do this we need defines for the extended attribute names in common code, I
    moved them up from JFS which had the nicest defintions.

    Signed-off-by: Christoph Hellwig
    Acked-by: Dave Kleikamp
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    akpm@osdl.org
     
  • Add vfs_getxattr, vfs_setxattr and vfs_removexattr helpers for common checks
    around invocation of the xattr methods. NFSD already was missing some of the
    checks and there will be more soon.

    Signed-off-by: Christoph Hellwig
    Cc: James Morris

    (James, I haven't touched selinux yet because it's doing various odd things
    and I'm not sure how it would interact with the security attribute fallbacks
    you added. Could you investigate whether it could use vfs_getxattr or if not
    add a __vfs_getxattr helper to share the bits it is fine with?)

    For NFSv4: instead of just converting it add an nfsd_getxattr helper for the
    code shared by NFSv2/3 and NFSv4 ACLs. In fact that code isn't even
    NFS-specific, but I'll wait for more users to pop up first before moving it to
    common code.

    Signed-off-by: Christoph Hellwig
    Acked-by: Dave Kleikamp
    Signed-off-by: Adrian Bunk
    Signed-off-by: Neil Brown
    Cc: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     

17 Apr, 2005

1 commit

  • 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