22 Nov, 2013

1 commit

  • Pull security subsystem updates from James Morris:
    "In this patchset, we finally get an SELinux update, with Paul Moore
    taking over as maintainer of that code.

    Also a significant update for the Keys subsystem, as well as
    maintenance updates to Smack, IMA, TPM, and Apparmor"

    and since I wanted to know more about the updates to key handling,
    here's the explanation from David Howells on that:

    "Okay. There are a number of separate bits. I'll go over the big bits
    and the odd important other bit, most of the smaller bits are just
    fixes and cleanups. If you want the small bits accounting for, I can
    do that too.

    (1) Keyring capacity expansion.

    KEYS: Consolidate the concept of an 'index key' for key access
    KEYS: Introduce a search context structure
    KEYS: Search for auth-key by name rather than target key ID
    Add a generic associative array implementation.
    KEYS: Expand the capacity of a keyring

    Several of the patches are providing an expansion of the capacity of a
    keyring. Currently, the maximum size of a keyring payload is one page.
    Subtract a small header and then divide up into pointers, that only gives
    you ~500 pointers on an x86_64 box. However, since the NFS idmapper uses
    a keyring to store ID mapping data, that has proven to be insufficient to
    the cause.

    Whatever data structure I use to handle the keyring payload, it can only
    store pointers to keys, not the keys themselves because several keyrings
    may point to a single key. This precludes inserting, say, and rb_node
    struct into the key struct for this purpose.

    I could make an rbtree of records such that each record has an rb_node
    and a key pointer, but that would use four words of space per key stored
    in the keyring. It would, however, be able to use much existing code.

    I selected instead a non-rebalancing radix-tree type approach as that
    could have a better space-used/key-pointer ratio. I could have used the
    radix tree implementation that we already have and insert keys into it by
    their serial numbers, but that means any sort of search must iterate over
    the whole radix tree. Further, its nodes are a bit on the capacious side
    for what I want - especially given that key serial numbers are randomly
    allocated, thus leaving a lot of empty space in the tree.

    So what I have is an associative array that internally is a radix-tree
    with 16 pointers per node where the index key is constructed from the key
    type pointer and the key description. This means that an exact lookup by
    type+description is very fast as this tells us how to navigate directly to
    the target key.

    I made the data structure general in lib/assoc_array.c as far as it is
    concerned, its index key is just a sequence of bits that leads to a
    pointer. It's possible that someone else will be able to make use of it
    also. FS-Cache might, for example.

    (2) Mark keys as 'trusted' and keyrings as 'trusted only'.

    KEYS: verify a certificate is signed by a 'trusted' key
    KEYS: Make the system 'trusted' keyring viewable by userspace
    KEYS: Add a 'trusted' flag and a 'trusted only' flag
    KEYS: Separate the kernel signature checking keyring from module signing

    These patches allow keys carrying asymmetric public keys to be marked as
    being 'trusted' and allow keyrings to be marked as only permitting the
    addition or linkage of trusted keys.

    Keys loaded from hardware during kernel boot or compiled into the kernel
    during build are marked as being trusted automatically. New keys can be
    loaded at runtime with add_key(). They are checked against the system
    keyring contents and if their signatures can be validated with keys that
    are already marked trusted, then they are marked trusted also and can
    thus be added into the master keyring.

    Patches from Mimi Zohar make this usable with the IMA keyrings also.

    (3) Remove the date checks on the key used to validate a module signature.

    X.509: Remove certificate date checks

    It's not reasonable to reject a signature just because the key that it was
    generated with is no longer valid datewise - especially if the kernel
    hasn't yet managed to set the system clock when the first module is
    loaded - so just remove those checks.

    (4) Make it simpler to deal with additional X.509 being loaded into the kernel.

    KEYS: Load *.x509 files into kernel keyring
    KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate

    The builder of the kernel now just places files with the extension ".x509"
    into the kernel source or build trees and they're concatenated by the
    kernel build and stuffed into the appropriate section.

    (5) Add support for userspace kerberos to use keyrings.

    KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches
    KEYS: Implement a big key type that can save to tmpfs

    Fedora went to, by default, storing kerberos tickets and tokens in tmpfs.
    We looked at storing it in keyrings instead as that confers certain
    advantages such as tickets being automatically deleted after a certain
    amount of time and the ability for the kernel to get at these tokens more
    easily.

    To make this work, two things were needed:

    (a) A way for the tickets to persist beyond the lifetime of all a user's
    sessions so that cron-driven processes can still use them.

    The problem is that a user's session keyrings are deleted when the
    session that spawned them logs out and the user's user keyring is
    deleted when the UID is deleted (typically when the last log out
    happens), so neither of these places is suitable.

    I've added a system keyring into which a 'persistent' keyring is
    created for each UID on request. Each time a user requests their
    persistent keyring, the expiry time on it is set anew. If the user
    doesn't ask for it for, say, three days, the keyring is automatically
    expired and garbage collected using the existing gc. All the kerberos
    tokens it held are then also gc'd.

    (b) A key type that can hold really big tickets (up to 1MB in size).

    The problem is that Active Directory can return huge tickets with lots
    of auxiliary data attached. We don't, however, want to eat up huge
    tracts of unswappable kernel space for this, so if the ticket is
    greater than a certain size, we create a swappable shmem file and dump
    the contents in there and just live with the fact we then have an
    inode and a dentry overhead. If the ticket is smaller than that, we
    slap it in a kmalloc()'d buffer"

    * 'for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (121 commits)
    KEYS: Fix keyring content gc scanner
    KEYS: Fix error handling in big_key instantiation
    KEYS: Fix UID check in keyctl_get_persistent()
    KEYS: The RSA public key algorithm needs to select MPILIB
    ima: define '_ima' as a builtin 'trusted' keyring
    ima: extend the measurement list to include the file signature
    kernel/system_certificate.S: use real contents instead of macro GLOBAL()
    KEYS: fix error return code in big_key_instantiate()
    KEYS: Fix keyring quota misaccounting on key replacement and unlink
    KEYS: Fix a race between negating a key and reading the error set
    KEYS: Make BIG_KEYS boolean
    apparmor: remove the "task" arg from may_change_ptraced_domain()
    apparmor: remove parent task info from audit logging
    apparmor: remove tsk field from the apparmor_audit_struct
    apparmor: fix capability to not use the current task, during reporting
    Smack: Ptrace access check mode
    ima: provide hash algo info in the xattr
    ima: enable support for larger default filedata hash algorithms
    ima: define kernel parameter 'ima_template=' to change configured default
    ima: add Kconfig default measurement list template
    ...

    Linus Torvalds
     

30 Oct, 2013

4 commits


16 Oct, 2013

2 commits

  • BugLink: http://bugs.launchpad.net/bugs/1235977

    The profile introspection seq file has a locking bug when policy is viewed
    from a virtual root (task in a policy namespace), introspection from the
    real root is not affected.

    The test for root
    while (parent) {
    is correct for the real root, but incorrect for tasks in a policy namespace.
    This allows the task to walk backup the policy tree past its virtual root
    causing it to be unlocked before the virtual root should be in the p_stop
    fn.

    This results in the following lockdep back trace:
    [ 78.479744] [ BUG: bad unlock balance detected! ]
    [ 78.479792] 3.11.0-11-generic #17 Not tainted
    [ 78.479838] -------------------------------------
    [ 78.479885] grep/2223 is trying to release lock (&ns->lock) at:
    [ 78.479952] [] mutex_unlock+0xe/0x10
    [ 78.480002] but there are no more locks to release!
    [ 78.480037]
    [ 78.480037] other info that might help us debug this:
    [ 78.480037] 1 lock held by grep/2223:
    [ 78.480037] #0: (&p->lock){+.+.+.}, at: [] seq_read+0x3d/0x3d0
    [ 78.480037]
    [ 78.480037] stack backtrace:
    [ 78.480037] CPU: 0 PID: 2223 Comm: grep Not tainted 3.11.0-11-generic #17
    [ 78.480037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
    [ 78.480037] ffffffff817bf3be ffff880007763d60 ffffffff817b97ef ffff8800189d2190
    [ 78.480037] ffff880007763d88 ffffffff810e1c6e ffff88001f044730 ffff8800189d2190
    [ 78.480037] ffffffff817bf3be ffff880007763e00 ffffffff810e5bd6 0000000724fe56b7
    [ 78.480037] Call Trace:
    [ 78.480037] [] ? mutex_unlock+0xe/0x10
    [ 78.480037] [] dump_stack+0x54/0x74
    [ 78.480037] [] print_unlock_imbalance_bug+0xee/0x100
    [ 78.480037] [] ? mutex_unlock+0xe/0x10
    [ 78.480037] [] lock_release_non_nested+0x226/0x300
    [ 78.480037] [] ? __mutex_unlock_slowpath+0xce/0x180
    [ 78.480037] [] ? mutex_unlock+0xe/0x10
    [ 78.480037] [] lock_release+0xac/0x310
    [ 78.480037] [] __mutex_unlock_slowpath+0x83/0x180
    [ 78.480037] [] mutex_unlock+0xe/0x10
    [ 78.480037] [] p_stop+0x51/0x90
    [ 78.480037] [] seq_read+0x288/0x3d0
    [ 78.480037] [] vfs_read+0x9e/0x170
    [ 78.480037] [] SyS_read+0x4c/0xa0
    [ 78.480037] [] system_call_fastpath+0x1a/0x1f

    Signed-off-by: John Johansen
    Signed-off-by: James Morris

    John Johansen
     
  • BugLink: http://bugs.launchpad.net/bugs/1235523

    This fixes the following kmemleak trace:
    unreferenced object 0xffff8801e8c35680 (size 32):
    comm "apparmor_parser", pid 691, jiffies 4294895667 (age 13230.876s)
    hex dump (first 32 bytes):
    e0 d3 4e b5 ac 6d f4 ed 3f cb ee 48 1c fd 40 cf ..N..m..?..H..@.
    5b cc e9 93 00 00 00 00 00 00 00 00 00 00 00 00 [...............
    backtrace:
    [] kmemleak_alloc+0x4e/0xb0
    [] __kmalloc+0x103/0x290
    [] aa_calc_profile_hash+0x6c/0x150
    [] aa_unpack+0x39d/0xd50
    [] aa_replace_profiles+0x3d/0xd80
    [] profile_replace+0x37/0x50
    [] vfs_write+0xbd/0x1e0
    [] SyS_write+0x4c/0xa0
    [] system_call_fastpath+0x1a/0x1f
    [] 0xffffffffffffffff

    Signed-off-by: John Johansen
    Signed-off-by: James Morris

    John Johansen
     

30 Sep, 2013

2 commits

  • The recent 3.12 pull request for apparmor was missing a couple rcu _protected
    access modifiers. Resulting in the follow suspicious RCU usage

    [ 29.804534] [ INFO: suspicious RCU usage. ]
    [ 29.804539] 3.11.0+ #5 Not tainted
    [ 29.804541] -------------------------------
    [ 29.804545] security/apparmor/include/policy.h:363 suspicious rcu_dereference_check() usage!
    [ 29.804548]
    [ 29.804548] other info that might help us debug this:
    [ 29.804548]
    [ 29.804553]
    [ 29.804553] rcu_scheduler_active = 1, debug_locks = 1
    [ 29.804558] 2 locks held by apparmor_parser/1268:
    [ 29.804560] #0: (sb_writers#9){.+.+.+}, at: [] file_start_write+0x27/0x29
    [ 29.804576] #1: (&ns->lock){+.+.+.}, at: [] aa_replace_profiles+0x166/0x57c
    [ 29.804589]
    [ 29.804589] stack backtrace:
    [ 29.804595] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+ #5
    [ 29.804599] Hardware name: ASUSTeK Computer Inc. UL50VT /UL50VT , BIOS 217 03/01/2010
    [ 29.804602] 0000000000000000 ffff8800b95a1d90 ffffffff8144eb9b ffff8800b94db540
    [ 29.804611] ffff8800b95a1dc0 ffffffff81087439 ffff880138cc3a18 ffff880138cc3a18
    [ 29.804619] ffff8800b9464a90 ffff880138cc3a38 ffff8800b95a1df0 ffffffff811f5084
    [ 29.804628] Call Trace:
    [ 29.804636] [] dump_stack+0x4e/0x82
    [ 29.804642] [] lockdep_rcu_suspicious+0xfc/0x105
    [ 29.804649] [] __aa_update_replacedby+0x53/0x7f
    [ 29.804655] [] __replace_profile+0x11f/0x1ed
    [ 29.804661] [] aa_replace_profiles+0x410/0x57c
    [ 29.804668] [] profile_replace+0x35/0x4c
    [ 29.804674] [] vfs_write+0xad/0x113
    [ 29.804680] [] SyS_write+0x44/0x7a
    [ 29.804687] [] system_call_fastpath+0x16/0x1b
    [ 29.804691]
    [ 29.804694] ===============================
    [ 29.804697] [ INFO: suspicious RCU usage. ]
    [ 29.804700] 3.11.0+ #5 Not tainted
    [ 29.804703] -------------------------------
    [ 29.804706] security/apparmor/policy.c:566 suspicious rcu_dereference_check() usage!
    [ 29.804709]
    [ 29.804709] other info that might help us debug this:
    [ 29.804709]
    [ 29.804714]
    [ 29.804714] rcu_scheduler_active = 1, debug_locks = 1
    [ 29.804718] 2 locks held by apparmor_parser/1268:
    [ 29.804721] #0: (sb_writers#9){.+.+.+}, at: [] file_start_write+0x27/0x29
    [ 29.804733] #1: (&ns->lock){+.+.+.}, at: [] aa_replace_profiles+0x166/0x57c
    [ 29.804744]
    [ 29.804744] stack backtrace:
    [ 29.804750] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+ #5
    [ 29.804753] Hardware name: ASUSTeK Computer Inc. UL50VT /UL50VT , BIOS 217 03/01/2010
    [ 29.804756] 0000000000000000 ffff8800b95a1d80 ffffffff8144eb9b ffff8800b94db540
    [ 29.804764] ffff8800b95a1db0 ffffffff81087439 ffff8800b95b02b0 0000000000000000
    [ 29.804772] ffff8800b9efba08 ffff880138cc3a38 ffff8800b95a1dd0 ffffffff811f4f94
    [ 29.804779] Call Trace:
    [ 29.804786] [] dump_stack+0x4e/0x82
    [ 29.804791] [] lockdep_rcu_suspicious+0xfc/0x105
    [ 29.804798] [] aa_free_replacedby_kref+0x4d/0x62
    [ 29.804804] [] ? aa_put_namespace+0x17/0x17
    [ 29.804810] [] kref_put+0x36/0x40
    [ 29.804816] [] __replace_profile+0x13a/0x1ed
    [ 29.804822] [] aa_replace_profiles+0x410/0x57c
    [ 29.804829] [] profile_replace+0x35/0x4c
    [ 29.804835] [] vfs_write+0xad/0x113
    [ 29.804840] [] SyS_write+0x44/0x7a
    [ 29.804847] [] system_call_fastpath+0x16/0x1b

    Reported-by: miles.lane@gmail.com
    CC: paulmck@linux.vnet.ibm.com
    Signed-off-by: John Johansen
    Signed-off-by: James Morris

    John Johansen
     
  • Use the shash interface, rather than the hash interface, when hashing
    AppArmor profiles. The shash interface does not use scatterlists and it
    is a better fit for what AppArmor needs.

    This fixes a kernel paging BUG when aa_calc_profile_hash() is passed a
    buffer from vmalloc(). The hash interface requires callers to handle
    vmalloc() buffers differently than what AppArmor was doing. Due to
    vmalloc() memory not being physically contiguous, each individual page
    behind the buffer must be assigned to a scatterlist with sg_set_page()
    and then the scatterlist passed to crypto_hash_update().

    The shash interface does not have that limitation and allows vmalloc()
    and kmalloc() buffers to be handled in the same manner.

    BugLink: https://launchpad.net/bugs/1216294/
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=62261

    Signed-off-by: Tyler Hicks
    Acked-by: Seth Arnold
    Signed-off-by: John Johansen
    Signed-off-by: James Morris

    Tyler Hicks
     

08 Sep, 2013

1 commit

  • Pull security subsystem updates from James Morris:
    "Nothing major for this kernel, just maintenance updates"

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (21 commits)
    apparmor: add the ability to report a sha1 hash of loaded policy
    apparmor: export set of capabilities supported by the apparmor module
    apparmor: add the profile introspection file to interface
    apparmor: add an optional profile attachment string for profiles
    apparmor: add interface files for profiles and namespaces
    apparmor: allow setting any profile into the unconfined state
    apparmor: make free_profile available outside of policy.c
    apparmor: rework namespace free path
    apparmor: update how unconfined is handled
    apparmor: change how profile replacement update is done
    apparmor: convert profile lists to RCU based locking
    apparmor: provide base for multiple profiles to be replaced at once
    apparmor: add a features/policy dir to interface
    apparmor: enable users to query whether apparmor is enabled
    apparmor: remove minimum size check for vmalloc()
    Smack: parse multiple rules per write to load2, up to PAGE_SIZE-1 bytes
    Smack: network label match fix
    security: smack: add a hash table to quicken smk_find_entry()
    security: smack: fix memleak in smk_write_rules_list()
    xattr: Constify ->name member of "struct xattr".
    ...

    Linus Torvalds
     

20 Aug, 2013

1 commit

  • The apparmor module parameters for param_ops_aabool and
    param_ops_aalockpolicy are both based off of the param_ops_bool,
    and can handle a NULL value passed in as val. Have it enable the
    new KERNEL_PARAM_FL_NOARGS flag to allow the parameters to be set
    without having to state "=y" or "=1".

    Cc: John Johansen
    Signed-off-by: Steven Rostedt
    Signed-off-by: Rusty Russell

    Steven Rostedt
     

15 Aug, 2013

15 commits


12 May, 2013

1 commit


28 Apr, 2013

13 commits