diff options
author | Jeff Vander Stoep <jeffv@google.com> | 2015-04-08 11:27:46 -0700 |
---|---|---|
committer | rogersb11 <brettrogers11@gmail.com> | 2015-11-09 11:40:43 -0500 |
commit | d177fbc2f0c263b06c18bda2eb46200a31bcbebd (patch) | |
tree | 70ccc31cdb4529be10956bd4228f9d731146e8ca /drivers/hid | |
parent | 90b542df96386ea6d875d51195c4b331fdc21d06 (diff) | |
download | kernel_samsung_smdk4412-d177fbc2f0c263b06c18bda2eb46200a31bcbebd.zip kernel_samsung_smdk4412-d177fbc2f0c263b06c18bda2eb46200a31bcbebd.tar.gz kernel_samsung_smdk4412-d177fbc2f0c263b06c18bda2eb46200a31bcbebd.tar.bz2 |
SELinux: per-command whitelisting of ioctls
note that this patch depends on a prior patch that is already in
android-3.4 but has not apparently found its way into the msm 3.4
branches (but is included in exynos and tegra),
https://android-review.googlesource.com/#/c/92962/
Extend the generic ioctl permission check with support for per-command
filtering. Source/target/class sets including the ioctl permission may
additionally include a set of commands. Example:
allow <source> <target>:<class> { 0x8910-0x8926 0x892A-0x8935 }
auditallow <source> <target>:<class> 0x892A
When ioctl commands are omitted only the permissions are checked. This
feature is intended to provide finer granularity for the ioctl
permission which may be too imprecise in some circumstances. 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_IOCTL_OPERATIONS=30 to account for the format change.
Bug: 18087110
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: Ibf0e36728f6f3f0d5af56ccdeddee40800af689d
SELinux: use deletion-safe iterator to free list
This code is not exercised by policy version 26, but will be upon
upgrade to policy version 30.
Bug: 18087110
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: I07c6f34607713294a6a12c43a64d9936f0602200
SELinux: ss: Fix policy write for ioctl operations
Security server omits the type field when writing out the contents of the
avtab from /sys/fs/selinux/policy. This leads to a corrupt output. No impact
on the running kernel or its loaded policy. Impacts CTS neverallow tests.
Bug: 20665861
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
(cherry picked from commit 8cdfb356b51e29494ca0b9e4e86727d6f841a52d)
Change-Id: I657e18013dd5a1f40052bc2b02dd8e0afee9bcfb
selinux: correctly label /proc inodes in use before the policy is loaded
commit f64410ec665479d7b4b77b7519e814253ed0f686 upstream.
This patch is based on an earlier patch by Eric Paris, he describes
the problem below:
"If an inode is accessed before policy load it will get placed on a
list of inodes to be initialized after policy load. After policy
load we call inode_doinit() which calls inode_doinit_with_dentry()
on all inodes accessed before policy load. In the case of inodes
in procfs that means we'll end up at the bottom where it does:
/* Default to the fs superblock SID. */
isec->sid = sbsec->sid;
if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) {
if (opt_dentry) {
isec->sclass = inode_mode_to_security_class(...)
rc = selinux_proc_get_sid(opt_dentry,
isec->sclass,
&sid);
if (rc)
goto out_unlock;
isec->sid = sid;
}
}
Since opt_dentry is null, we'll never call selinux_proc_get_sid()
and will leave the inode labeled with the label on the superblock.
I believe a fix would be to mimic the behavior of xattrs. Look
for an alias of the inode. If it can't be found, just leave the
inode uninitialized (and pick it up later) if it can be found, we
should be able to call selinux_proc_get_sid() ..."
On a system exhibiting this problem, you will notice a lot of files in
/proc with the generic "proc_t" type (at least the ones that were
accessed early in the boot), for example:
# ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
system_u:object_r:proc_t:s0 /proc/sys/kernel/shmmax
However, with this patch in place we see the expected result:
# ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
system_u:object_r:sysctl_kernel_t:s0 /proc/sys/kernel/shmmax
Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Acked-by: Eric Paris <eparis@redhat.com>
Change-Id: I7742b4b7e53b45e4dd13d99c39553a927aa4a7e9
Diffstat (limited to 'drivers/hid')
0 files changed, 0 insertions, 0 deletions