Eric Lee / smarc-fsl-linux-kernel

20 Mar, 2013

1 commit

  • e05b6f982   Smack: add support for modification of existing rules ... Browse Code »

    Rule modifications are enabled via /smack/change-rule. Format is as follows:
    "Subject Object rwaxt rwaxt"

    First two strings are subject and object labels up to 255 characters.
    Third string contains permissions to enable.
    Fourth string contains permissions to disable.

    All unmentioned permissions will be left unchanged.
    If no rule previously existed, it will be created.

    Targeted for git://git.gitorious.org/smack-next/kernel.git

    Signed-off-by: Rafal Krypa

    Rafal Krypa
     

18 Dec, 2012

1 commit

03 Oct, 2012

2 commits

27 Sep, 2012

1 commit

19 Sep, 2012

1 commit

13 Sep, 2012

1 commit

  • d4f65b5d2   KEYS: Add payload preparsing opportunity prior to key instantiate or update ... Browse Code »

    Give the key type the opportunity to preparse the payload prior to the
    instantiation and update routines being called. This is done with the
    provision of two new key type operations:

    int (*preparse)(struct key_preparsed_payload *prep);
    void (*free_preparse)(struct key_preparsed_payload *prep);

    If the first operation is present, then it is called before key creation (in
    the add/update case) or before the key semaphore is taken (in the update and
    instantiate cases). The second operation is called to clean up if the first
    was called.

    preparse() is given the opportunity to fill in the following structure:

    struct key_preparsed_payload {
    char *description;
    void *type_data[2];
    void *payload;
    const void *data;
    size_t datalen;
    size_t quotalen;
    };

    Before the preparser is called, the first three fields will have been cleared,
    the payload pointer and size will be stored in data and datalen and the default
    quota size from the key_type struct will be stored into quotalen.

    The preparser may parse the payload in any way it likes and may store data in
    the type_data[] and payload fields for use by the instantiate() and update()
    ops.

    The preparser may also propose a description for the key by attaching it as a
    string to the description field. This can be used by passing a NULL or ""
    description to the add_key() system call or the key_create_or_update()
    function. This cannot work with request_key() as that required the description
    to tell the upcall about the key to be created.

    This, for example permits keys that store PGP public keys to generate their own
    name from the user ID and public key fingerprint in the key.

    The instantiate() and update() operations are then modified to look like this:

    int (*instantiate)(struct key *key, struct key_preparsed_payload *prep);
    int (*update)(struct key *key, struct key_preparsed_payload *prep);

    and the new payload data is passed in *prep, whether or not it was preparsed.

    Signed-off-by: David Howells

    David Howells
     

10 Aug, 2012

1 commit

  • 9d8dad742   Yama: higher restrictions should block PTRACE_TRACEME ... Browse Code »

    The higher ptrace restriction levels should be blocking even
    PTRACE_TRACEME requests. The comments in the LSM documentation are
    misleading about when the checks happen (the parent does not go through
    security_ptrace_access_check() on a PTRACE_TRACEME call).

    Signed-off-by: Kees Cook
    Cc: stable@vger.kernel.org # 3.5.x and later
    Signed-off-by: James Morris

    Kees Cook
     

15 May, 2012

1 commit

  • f7112e6c9   Smack: allow for significantly longer Smack labels v4 ... Browse Code »

    V4 updated to current linux-security#next
    Targeted for git://gitorious.org/smack-next/kernel.git

    Modern application runtime environments like to use
    naming schemes that are structured and generated without
    human intervention. Even though the Smack limit of 23
    characters for a label name is perfectly rational for
    human use there have been complaints that the limit is
    a problem in environments where names are composed from
    a set or sources, including vendor, author, distribution
    channel and application name. Names like

    softwarehouse-pgwodehouse-coolappstore-mellowmuskrats

    are becoming harder to avoid. This patch introduces long
    label support in Smack. Labels are now limited to 255
    characters instead of the old 23.

    The primary reason for limiting the labels to 23 characters
    was so they could be directly contained in CIPSO category sets.
    This is still done were possible, but for labels that are too
    large a mapping is required. This is perfectly safe for communication
    that stays "on the box" and doesn't require much coordination
    between boxes beyond what would have been required to keep label
    names consistent.

    The bulk of this patch is in smackfs, adding and updating
    administrative interfaces. Because existing APIs can't be
    changed new ones that do much the same things as old ones
    have been introduced.

    The Smack specific CIPSO data representation has been removed
    and replaced with the data format used by netlabel. The CIPSO
    header is now computed when a label is imported rather than
    on use. This results in improved IP performance. The smack
    label is now allocated separately from the containing structure,
    allowing for larger strings.

    Four new /smack interfaces have been introduced as four
    of the old interfaces strictly required labels be specified
    in fixed length arrays.

    The access interface is supplemented with the check interface:
    access "Subject Object rwxat"
    access2 "Subject Object rwaxt"

    The load interface is supplemented with the rules interface:
    load "Subject Object rwxat"
    load2 "Subject Object rwaxt"

    The load-self interface is supplemented with the self-rules interface:
    load-self "Subject Object rwxat"
    load-self2 "Subject Object rwaxt"

    The cipso interface is supplemented with the wire interface:
    cipso "Subject lvl cnt c1 c2 ..."
    cipso2 "Subject lvl cnt c1 c2 ..."

    The old interfaces are maintained for compatibility.

    Signed-off-by: Casey Schaufler

    Casey Schaufler
     

11 May, 2012

1 commit

  • fd75815f7   KEYS: Add invalidation support ... Browse Code »

    Add support for invalidating a key - which renders it immediately invisible to
    further searches and causes the garbage collector to immediately wake up,
    remove it from keyrings and then destroy it when it's no longer referenced.

    It's better not to do this with keyctl_revoke() as that marks the key to start
    returning -EKEYREVOKED to searches when what is actually desired is to have the
    key refetched.

    To invalidate a key the caller must be granted SEARCH permission by the key.
    This may be too strict. It may be better to also permit invalidation if the
    caller has any of READ, WRITE or SETATTR permission.

    The primary use for this is to evict keys that are cached in special keyrings,
    such as the DNS resolver or an ID mapper.

    Signed-off-by: David Howells

    David Howells
     

04 May, 2012

1 commit

26 Apr, 2012

1 commit

19 Apr, 2012

1 commit

  • 389da25f9   Yama: add additional ptrace scopes ... Browse Code »
    43

    This expands the available Yama ptrace restrictions to include two more
    modes. Mode 2 requires CAP_SYS_PTRACE for PTRACE_ATTACH, and mode 3
    completely disables PTRACE_ATTACH (and locks the sysctl).

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

    Kees Cook
     

22 Mar, 2012

1 commit

  • 3556485f1   Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security ... Browse Code »

    Pull security subsystem updates for 3.4 from James Morris:
    "The main addition here is the new Yama security module from Kees Cook,
    which was discussed at the Linux Security Summit last year. Its
    purpose is to collect miscellaneous DAC security enhancements in one
    place. This also marks a departure in policy for LSM modules, which
    were previously limited to being standalone access control systems.
    Chromium OS is using Yama, and I believe there are plans for Ubuntu,
    at least.

    This patchset also includes maintenance updates for AppArmor, TOMOYO
    and others."

    Fix trivial conflict in due to the jumo_label->static_key
    rename.

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (38 commits)
    AppArmor: Fix location of const qualifier on generated string tables
    TOMOYO: Return error if fails to delete a domain
    AppArmor: add const qualifiers to string arrays
    AppArmor: Add ability to load extended policy
    TOMOYO: Return appropriate value to poll().
    AppArmor: Move path failure information into aa_get_name and rename
    AppArmor: Update dfa matching routines.
    AppArmor: Minor cleanup of d_namespace_path to consolidate error handling
    AppArmor: Retrieve the dentry_path for error reporting when path lookup fails
    AppArmor: Add const qualifiers to generated string tables
    AppArmor: Fix oops in policy unpack auditing
    AppArmor: Fix error returned when a path lookup is disconnected
    KEYS: testing wrong bit for KEY_FLAG_REVOKED
    TOMOYO: Fix mount flags checking order.
    security: fix ima kconfig warning
    AppArmor: Fix the error case for chroot relative path name lookup
    AppArmor: fix mapping of META_READ to audit and quiet flags
    AppArmor: Fix underflow in xindex calculation
    AppArmor: Fix dropping of allowed operations that are force audited
    AppArmor: Add mising end of structure test to caps unpacking
    ...

    Linus Torvalds
     

07 Mar, 2012

1 commit

16 Feb, 2012

1 commit

  • bf06189e4   Yama: add PR_SET_PTRACER_ANY ... Browse Code »

    For a process to entirely disable Yama ptrace restrictions, it can use
    the special PR_SET_PTRACER_ANY pid to indicate that any otherwise allowed
    process may ptrace it. This is stronger than calling PR_SET_PTRACER with
    pid "1" because it includes processes in external pid namespaces. This is
    currently needed by the Chrome renderer, since its crash handler (Breakpad)
    runs external to the renderer's pid namespace.

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

    Kees Cook
     

10 Feb, 2012

1 commit

  • 2d514487f   security: Yama LSM ... Browse Code »

    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
     

19 Jan, 2012

1 commit

  • 700920eb5   KEYS: Allow special keyrings to be cleared ... Browse Code »

    The kernel contains some special internal keyrings, for instance the DNS
    resolver keyring :

    2a93faf1 I----- 1 perm 1f030000 0 0 keyring .dns_resolver: empty

    It would occasionally be useful to allow the contents of such keyrings to be
    flushed by root (cache invalidation).

    Allow a flag to be set on a keyring to mark that someone possessing the
    sysadmin capability can clear the keyring, even without normal write access to
    the keyring.

    Set this flag on the special keyrings created by the DNS resolver, the NFS
    identity mapper and the CIFS identity mapper.

    Signed-off-by: David Howells
    Acked-by: Jeff Layton
    Acked-by: Steve Dickson
    Signed-off-by: James Morris

    David Howells
     

16 Nov, 2011

2 commits

28 Sep, 2011

1 commit

  • 395cf9691   doc: fix broken references ... Browse Code »

    There are numerous broken references to Documentation files (in other
    Documentation files, in comments, etc.). These broken references are
    caused by typo's in the references, and by renames or removals of the
    Documentation files. Some broken references are simply odd.

    Fix these broken references, sometimes by dropping the irrelevant text
    they were part of.

    Signed-off-by: Paul Bolle
    Signed-off-by: Jiri Kosina

    Paul Bolle
     

30 Jun, 2011

1 commit

27 Jun, 2011

2 commits

  • 79a73d188   encrypted-keys: add ecryptfs format support ... Browse Code »

    The 'encrypted' key type defines its own payload format which contains a
    symmetric key randomly generated that cannot be used directly to mount
    an eCryptfs filesystem, because it expects an authentication token
    structure.

    This patch introduces the new format 'ecryptfs' that allows to store an
    authentication token structure inside the encrypted key payload containing
    a randomly generated symmetric key, as the same for the format 'default'.

    More details about the usage of encrypted keys with the eCryptfs
    filesystem can be found in the file 'Documentation/keys-ecryptfs.txt'.

    Signed-off-by: Roberto Sassu
    Acked-by: Gianluca Ramunno
    Acked-by: Tyler Hicks
    Signed-off-by: Mimi Zohar

    Roberto Sassu
     
  • 4e561d388   encrypted-keys: add key format support ... Browse Code »

    This patch introduces a new parameter, called 'format', that defines the
    format of data stored by encrypted keys. The 'default' format identifies
    encrypted keys containing only the symmetric key, while other formats can
    be defined to support additional information. The 'format' parameter is
    written in the datablob produced by commands 'keyctl print' or
    'keyctl pipe' and is integrity protected by the HMAC.

    Signed-off-by: Roberto Sassu
    Acked-by: Gianluca Ramunno
    Acked-by: David Howells
    Signed-off-by: Mimi Zohar

    Roberto Sassu
     

20 May, 2011

1 commit