- 03 Feb, 2016 2 commits
-
-
Jaegeuk Kim authored
This patch introduces a generic ioctl for fs shutdown. Change-Id: I452ee16b0078a2704b8026962e5bd07b67710c06 Signed-off-by:
sub77 <sub77@ymail.com>
-
- 25 Jan, 2016 6 commits
-
-
sub77 authored
Change-Id: I3ce5a38d22946ec6b67e69f18e66c2d1ee22f9f3
-
Syam Sidhardhan authored
In this API, we were using sizeof operator for an array given as function argument, which is invalid. However this API is not used anywhere. Change-Id: I80a43472b35f0f6c117624de2b2907b37eefb786 Signed-off-by:
Syam Sidhardhan <s.syam@samsung.com>
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
- 24 Jan, 2016 32 commits
-
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
Steve Kondik authored
Change-Id: I24ac3d82de6c919b392087e68eb9e471885a0143 Signed-off-by:
sub77 <sub77@ymail.com>
-
Steve Kondik authored
Change-Id: I1ca2fe7e175f696060787630e4aadad82d84394d Signed-off-by:
sub77 <sub77@ymail.com>
-
Steve Kondik authored
* Tools can set the value easily from userspace. Change-Id: I1ec8c1e023eb1eb34b5c9e495496afabcc4bdaf1 Signed-off-by:
sub77 <sub77@ymail.com>
-
Robert Rozic authored
*kk_3.5_rb1.18 Signed-off-by:
sub77 <sub77@ymail.com>
-
sub77 authored
-
sub77 authored
-
sub77 authored
-
Nikola Majkic authored
This reverts commit 853ababe.
-
Stephen Smalley authored
rootfs (ramfs) can support setting of security contexts by userspace due to the vfs fallback behavior of calling the security module to set the in-core inode state for security.* attributes when the filesystem does not provide an xattr handler. No xattr handler required as the inodes are pinned in memory and have no backing store. This is useful in allowing early userspace to label individual files within a rootfs while still providing a policy-defined default via genfs. Change-Id: I866bd3a8ed626d82007a2108ede978dd6e5a189b Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>
-
David Howells authored
The following sequence of commands: i=`keyctl add user a a @s` keyctl request2 keyring foo bar @t keyctl unlink $i @s tries to invoke an upcall to instantiate a keyring if one doesn't already exist by that name within the user's keyring set. However, if the upcall fails, the code sets keyring->type_data.reject_error to -ENOKEY or some other error code. When the key is garbage collected, the key destroy function is called unconditionally and keyring_destroy() uses list_empty() on keyring->type_data.link - which is in a union with reject_error. Subsequently, the kernel tries to unlink the keyring from the keyring names list - which oopses like this: BUG: unable to handle kernel paging request at 00000000ffffff8a IP: [<ffffffff8126e051>] keyring_destroy+0x3d/0x88 ... Workqueue: events key_garbage_collector ... RIP: 0010:[<ffffffff8126e051>] keyring_destroy+0x3d/0x88 RSP: 0018:ffff88003e2f3d30 EFLAGS: 00010203 RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40 RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000 R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900 R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000 ... CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0 ... Call Trace: [<ffffffff8126c756>] key_gc_unused_keys.constprop.1+0x5d/0x10f [<ffffffff8126ca71>] key_garbage_collector+0x1fa/0x351 [<ffffffff8105ec9b>] process_one_work+0x28e/0x547 [<ffffffff8105fd17>] worker_thread+0x26e/0x361 [<ffffffff8105faa9>] ? rescuer_thread+0x2a8/0x2a8 [<ffffffff810648ad>] kthread+0xf3/0xfb [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2 [<ffffffff815f2ccf>] ret_from_fork+0x3f/0x70 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2 Note the value in RAX. This is a 32-bit representation of -ENOKEY. The solution is to only call ->destroy() if the key was successfully instantiated. Change-Id: Ia52370813b7e8231fdd99d2a208340af1c7b4007 Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Tested-by:
Dmitry Vyukov <dvyukov@google.com>
-
David Howells authored
There appears to be a race between: (1) key_gc_unused_keys() which frees key->security and then calls keyring_destroy() to unlink the name from the name list (2) find_keyring_by_name() which calls key_permission(), thus accessing key->security, on a key before checking to see whether the key usage is 0 (ie. the key is dead and might be cleaned up). Fix this by calling ->destroy() before cleaning up the core key data - including key->security. Change-Id: I4b9b89af020e6348af095e9014bf23b5eb1a9ef9 Reported-by:
Petr Matousek <pmatouse@redhat.com> Signed-off-by:
David Howells <dhowells@redhat.com>
-
David Howells authored
Make the keys garbage collector invoke synchronize_rcu() prior to destroying keys with a zero usage count. This means that a key can be examined under the RCU read lock in the safe knowledge that it won't get deallocated until after the lock is released - even if its usage count becomes zero whilst we're looking at it. This is useful in keyring search vs key link. Consider a keyring containing a link to a key. That link can be replaced in-place in the keyring without requiring an RCU copy-and-replace on the keyring contents without breaking a search underway on that keyring when the displaced key is released, provided the key is actually destroyed only after the RCU read lock held by the search algorithm is released. This permits __key_link() to replace a key without having to reallocate the key payload. A key gets replaced if a new key being linked into a keyring has the same type and description. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Jeff Layton <jlayton@redhat.com> Conflicts: security/keys/gc.c Change-Id: Ifd8549b5b906c638d63c358ce1f34acd81139207
-
David Howells authored
Make use of the previous patch that makes the garbage collector perform RCU synchronisation before destroying defunct keys. Key pointers can now be replaced in-place without creating a new keyring payload and replacing the whole thing as the discarded keys will not be destroyed until all currently held RCU read locks are released. If the keyring payload space needs to be expanded or contracted, then a replacement will still need allocating, and the original will still have to be freed by RCU. Change-Id: I6c4f784f120951fb51ac9c23856ea37f51770bb9 Signed-off-by:
David Howells <dhowells@redhat.com>
-
David Howells authored
If a user key gets negatively instantiated, an error code is cached in the payload area. A negatively instantiated key may be then be positively instantiated by updating it with valid data. However, the ->update key type method must be aware that the error code may be there. The following may be used to trigger the bug in the user key type: keyctl request2 user user "" @u keyctl add user user "a" @u which manifests itself as: BUG: unable to handle kernel paging request at 00000000ffffff8a IP: [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046 PGD 7cc30067 PUD 0 Oops: 0002 [#1] SMP Modules linked in: CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000 RIP: 0010:[<ffffffff810a376f>] [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046 RSP: 0018:ffff88003dd8bdb0 EFLAGS: 00010246 RAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001 RDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82 RBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82 R13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700 FS: 0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0 Stack: ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82 ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5 ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620 Call Trace: [<ffffffff810a39e5>] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136 [<ffffffff812a31ab>] user_update+0x8b/0xb0 security/keys/user_defined.c:129 [< inline >] __key_update security/keys/key.c:730 [<ffffffff8129e5c1>] key_create_or_update+0x291/0x440 security/keys/key.c:908 [< inline >] SYSC_add_key security/keys/keyctl.c:125 [<ffffffff8129fc21>] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60 [<ffffffff8185f617>] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185 Note the error code (-ENOKEY) in EDX. A similar bug can be tripped by: keyctl request2 trusted user "" @u keyctl add trusted user "a" @u This should also affect encrypted keys - but that has to be correctly parameterised or it will fail with EINVAL before getting to the bit that will crashes. Change-Id: I171d566f431c56208e1fe279f466d2d399a9ac7c Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
James Morris <james.l.morris@oracle.com>
-
Stephen Smalley authored
Support per-file labeling of sysfs and pstore files based on genfscon policy entries. This is safe because the sysfs and pstore directory tree cannot be manipulated by userspace, except to unlink pstore entries. This provides an alternative method of assigning per-file labeling to sysfs or pstore files without needing to set the labels from userspace on each boot. The advantages of this approach are that the labels are assigned as soon as the dentry is first instantiated and userspace does not need to walk the sysfs or pstore tree and set the labels on each boot. The limitations of this approach are that the labels can only be assigned based on pathname prefix matching. You can initially assign labels using this mechanism and then change them at runtime via setxattr if allowed to do so by policy. Change-Id: If5999785fdc1d24d869b23ae35cd302311e94562 Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov> Suggested-by:
Dominick Grift <dac.override@gmail.com>
-
Stephen Smalley authored
upstream commit 6f29997f4a3117169eeabd41dbea4c1bd94a739c Add support for per-file labeling of debugfs files so that we can distinguish them in policy. This is particularly important in Android where certain debugfs files have to be writable by apps and therefore the debugfs directory tree can be read and searched by all. Since debugfs is entirely kernel-generated, the directory tree is immutable by userspace, and the inodes are pinned in memory, we can simply use the same approach as with proc and label the inodes from policy based on pathname from the root of the debugfs filesystem. Generalize the existing labeling support used for proc and reuse it for debugfs too. [sds: Back-ported to 3.4. superblock_security_struct flags field is only unsigned char in 3.4 so we have to redefine SE_SBGENFS. However, this definition is kernel-private, not exposed to userspace or stored anywhere persistent. Also depends on I7742b4b7e53b45e4dd13d99c39553a927aa4a7e9.] Change-Id: I6460fbed6bb6bd36eb8554ac8c4fdd574edf3b07 Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>
-
Jeff Vander Stoep authored
NOT intended for new Android devices - this commit is unnecessary for a target device that does not have a previous M variant. DO NOT upstream. Android only. Motivation: This commit mitigates a mismatch between selinux kernel and selinux userspace. The selinux ioctl white-listing binary policy format that was accepted into Android M differs slightly from what was later accepted into the upstream kernel. This leaves Android master branch kernels incompatible with Android M releases. This patch restores backwards compatibility. This is important because: 1. kernels may be updated on a different cycle than the rest of the OS e.g. security patching. 2. Android M bringup may still be ongoing for some devices. The same kernel should work for both M and master. Backwards compatibility is achieved by checking for an Android M policy characteristic during initial policy read and converting to upstream policy format. The inverse conversion is done for policy write as required for CTS testing. Bug: 22846070 Change-Id: I2f1ee2eee402f37cf3c9df9f9e03c1b9ddec1929 Signed-off-by:
Jeff Vander Stoep <jeffv@google.com>
-
Jeff Vander Stoep authored
(cherry picked from commit fa1aa143ac4a682c7f5fd52a3cf05f5a6fe44a0a) Add extended permissions logic to selinux. Extended permissions provides additional permissions in 256 bit increments. Extend the generic ioctl permission check to use the extended permissions for per-command filtering. Source/target/class sets including the ioctl permission may additionally include a set of commands. Example: allowxperm <source> <target>:<class> ioctl unpriv_app_socket_cmds auditallowxperm <source> <target>:<class> ioctl priv_gpu_cmds Where unpriv_app_socket_cmds and priv_gpu_cmds are macros representing commonly granted sets of ioctl commands. When ioctl commands are omitted only the permissions are checked. This feature is intended to provide finer granularity for the ioctl permission that may be too imprecise. For example, the same driver may use ioctls to provide important and benign functionality such as driver version or socket type as well as dangerous capabilities such as debugging features, read/write/execute to physical memory or access to sensitive data. Per-command filtering provides a mechanism to reduce the attack surface of the kernel, and limit applications to the subset of commands required. The format of the policy binary has been modified to include ioctl commands, and the policy version number has been incremented to POLICYDB_VERSION_XPERMS_IOCTL=30 to account for the format change. The extended permissions logic is deliberately generic to allow components to be reused e.g. netlink filters Signed-off-by:
Jeff Vander Stoep <jeffv@google.com> Acked-by:
Nick Kralevich <nnk@google.com> Signed-off-by:
Paul Moore <pmoore@redhat.com> Bug: 22846070 Change-Id: I299dc776d2f98d593ecc051707110c92a085350f
-
Jeff Vander Stoep authored
(cherry pick from commit 671a2781ff01abf4fdc8904881fc3abd3a8279af) Add information about ioctl calls to the LSM audit data. Log the file path and command number. Signed-off-by:
Jeff Vander Stoep <jeffv@google.com> Acked-by:
Nick Kralevich <nnk@google.com> [PM: subject line tweak] Signed-off-by:
Paul Moore <pmoore@redhat.com> Bug: 22846070 Change-Id: I4a7678294e0a3075f57bd77c76fd17e6f0d33e75
-
Jeff Vander Stoep authored
(cherry pick from commit 83d4a806ae46397f606de7376b831524bd3a21e5) Commit f01e1af4 ("selinux: don't pass in NULL avd to avc_has_perm_noaudit") made this pointer reassignment unnecessary. Avd should continue to reference the stack-based copy. Signed-off-by:
Jeff Vander Stoep <jeffv@google.com> Acked-by:
Stephen Smalley <sds@tycho.nsa.gov> [PM: tweaked subject line] Signed-off-by:
Paul Moore <pmoore@redhat.com> Bug: 22846070 Change-Id: Ie33688d163870705272607309a27fb7c8f870748
-
Jeff Vander Stoep authored
This reverts commit 643ce43c226cdfa73bcac2fa91f1f8a3dfd171a2. Bug: 22846070 Change-Id: I5dde1878e5baac43b4968141c0dc60b70e042183 Signed-off-by:
Jeff Vander Stoep <jeffv@google.com>
-
Jeff Vander Stoep authored
This reverts commit bc84b4adb1469e3d05ad76c304a4c545feaf1f88. Bug: 22846070 Change-Id: Ib4cb130b2225ea2e22556ff852313e0de7dddcab Signed-off-by:
Jeff Vander Stoep <jeffv@google.com>
-