In function cap_task_prctl(), we would allocate a credential
unconditionally and then check if we support the requested function.
If not we would release this credential with abort_creds() by using
RCU method. But on some archs such as powerpc, the sys_prctl is heavily
used to get/set the floating point exception mode. So the unnecessary
allocating/releasing of credential not only introduce runtime overhead
but also do cause OOM due to the RCU implementation.
This patch removes abort_creds() from cap_task_prctl() by calling
prepare_creds() only when we need to modify it.
Reported-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reviewed-by: Paul Moore <paul@paul-moore.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
(cherry picked from commit 6d6f3328422a3bc56b0d8dd026a5de845d2abfa7)
Bug: 35074030
Test: Builds.
Change-Id: Ic7b0d01f4c23328b134084a5585599883aed6345
Signed-off-by: Jorge Lucangeli Obes <jorgelo@google.com>
Credit where credit is due: this idea comes from Christoph Lameter with
a lot of valuable input from Serge Hallyn. This patch is heavily based
on Christoph's patch.
===== The status quo =====
On Linux, there are a number of capabilities defined by the kernel. To
perform various privileged tasks, processes can wield capabilities that
they hold.
Each task has four capability masks: effective (pE), permitted (pP),
inheritable (pI), and a bounding set (X). When the kernel checks for a
capability, it checks pE. The other capability masks serve to modify
what capabilities can be in pE.
Any task can remove capabilities from pE, pP, or pI at any time. If a
task has a capability in pP, it can add that capability to pE and/or pI.
If a task has CAP_SETPCAP, then it can add any capability to pI, and it
can remove capabilities from X.
Tasks are not the only things that can have capabilities; files can also
have capabilities. A file can have no capabilty information at all [1].
If a file has capability information, then it has a permitted mask (fP)
and an inheritable mask (fI) as well as a single effective bit (fE) [2].
File capabilities modify the capabilities of tasks that execve(2) them.
A task that successfully calls execve has its capabilities modified for
the file ultimately being excecuted (i.e. the binary itself if that
binary is ELF or for the interpreter if the binary is a script.) [3] In
the capability evolution rules, for each mask Z, pZ represents the old
value and pZ' represents the new value. The rules are:
pP' = (X & fP) | (pI & fI)
pI' = pI
pE' = (fE ? pP' : 0)
X is unchanged
For setuid binaries, fP, fI, and fE are modified by a moderately
complicated set of rules that emulate POSIX behavior. Similarly, if
euid == 0 or ruid == 0, then fP, fI, and fE are modified differently
(primary, fP and fI usually end up being the full set). For nonroot
users executing binaries with neither setuid nor file caps, fI and fP
are empty and fE is false.
As an extra complication, if you execute a process as nonroot and fE is
set, then the "secure exec" rules are in effect: AT_SECURE gets set,
LD_PRELOAD doesn't work, etc.
This is rather messy. We've learned that making any changes is
dangerous, though: if a new kernel version allows an unprivileged
program to change its security state in a way that persists cross
execution of a setuid program or a program with file caps, this
persistent state is surprisingly likely to allow setuid or file-capped
programs to be exploited for privilege escalation.
===== The problem =====
Capability inheritance is basically useless.
If you aren't root and you execute an ordinary binary, fI is zero, so
your capabilities have no effect whatsoever on pP'. This means that you
can't usefully execute a helper process or a shell command with elevated
capabilities if you aren't root.
On current kernels, you can sort of work around this by setting fI to
the full set for most or all non-setuid executable files. This causes
pP' = pI for nonroot, and inheritance works. No one does this because
it's a PITA and it isn't even supported on most filesystems.
If you try this, you'll discover that every nonroot program ends up with
secure exec rules, breaking many things.
This is a problem that has bitten many people who have tried to use
capabilities for anything useful.
===== The proposed change =====
This patch adds a fifth capability mask called the ambient mask (pA).
pA does what most people expect pI to do.
pA obeys the invariant that no bit can ever be set in pA if it is not
set in both pP and pI. Dropping a bit from pP or pI drops that bit from
pA. This ensures that existing programs that try to drop capabilities
still do so, with a complication. Because capability inheritance is so
broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, and
then calling execve effectively drops capabilities. Therefore,
setresuid from root to nonroot conditionally clears pA unless
SECBIT_NO_SETUID_FIXUP is set. Processes that don't like this can
re-add bits to pA afterwards.
The capability evolution rules are changed:
pA' = (file caps or setuid or setgid ? 0 : pA)
pP' = (X & fP) | (pI & fI) | pA'
pI' = pI
pE' = (fE ? pP' : pA')
X is unchanged
If you are nonroot but you have a capability, you can add it to pA. If
you do so, your children get that capability in pA, pP, and pE. For
example, you can set pA = CAP_NET_BIND_SERVICE, and your children can
automatically bind low-numbered ports. Hallelujah!
Unprivileged users can create user namespaces, map themselves to a
nonzero uid, and create both privileged (relative to their namespace)
and unprivileged process trees. This is currently more or less
impossible. Hallelujah!
You cannot use pA to try to subvert a setuid, setgid, or file-capped
program: if you execute any such program, pA gets cleared and the
resulting evolution rules are unchanged by this patch.
Users with nonzero pA are unlikely to unintentionally leak that
capability. If they run programs that try to drop privileges, dropping
privileges will still work.
It's worth noting that the degree of paranoia in this patch could
possibly be reduced without causing serious problems. Specifically, if
we allowed pA to persist across executing non-pA-aware setuid binaries
and across setresuid, then, naively, the only capabilities that could
leak as a result would be the capabilities in pA, and any attacker
*already* has those capabilities. This would make me nervous, though --
setuid binaries that tried to privilege-separate might fail to do so,
and putting CAP_DAC_READ_SEARCH or CAP_DAC_OVERRIDE into pA could have
unexpected side effects. (Whether these unexpected side effects would
be exploitable is an open question.) I've therefore taken the more
paranoid route. We can revisit this later.
An alternative would be to require PR_SET_NO_NEW_PRIVS before setting
ambient capabilities. I think that this would be annoying and would
make granting otherwise unprivileged users minor ambient capabilities
(CAP_NET_BIND_SERVICE or CAP_NET_RAW for example) much less useful than
it is with this patch.
===== Footnotes =====
[1] Files that are missing the "security.capability" xattr or that have
unrecognized values for that xattr end up with has_cap set to false.
The code that does that appears to be complicated for no good reason.
[2] The libcap capability mask parsers and formatters are dangerously
misleading and the documentation is flat-out wrong. fE is *not* a mask;
it's a single bit. This has probably confused every single person who
has tried to use file capabilities.
[3] Linux very confusingly processes both the script and the interpreter
if applicable, for reasons that elude me. The results from thinking
about a script's file capabilities and/or setuid bits are mostly
discarded.
Preliminary userspace code is here, but it needs updating:
https://git.kernel.org/cgit/linux/kernel/git/luto/util-linux-playground.git/commit/?h=cap_ambient&id=7f5afbd175d2
Here is a test program that can be used to verify the functionality
(from Christoph):
/*
* Test program for the ambient capabilities. This program spawns a shell
* that allows running processes with a defined set of capabilities.
*
* (C) 2015 Christoph Lameter <cl@linux.com>
* Released under: GPL v3 or later.
*
*
* Compile using:
*
* gcc -o ambient_test ambient_test.o -lcap-ng
*
* This program must have the following capabilities to run properly:
* Permissions for CAP_NET_RAW, CAP_NET_ADMIN, CAP_SYS_NICE
*
* A command to equip the binary with the right caps is:
*
* setcap cap_net_raw,cap_net_admin,cap_sys_nice+p ambient_test
*
*
* To get a shell with additional caps that can be inherited by other processes:
*
* ./ambient_test /bin/bash
*
*
* Verifying that it works:
*
* From the bash spawed by ambient_test run
*
* cat /proc/$$/status
*
* and have a look at the capabilities.
*/
/*
* Definitions from the kernel header files. These are going to be removed
* when the /usr/include files have these defined.
*/
static void set_ambient_cap(int cap)
{
int rc;
capng_get_caps_process();
rc = capng_update(CAPNG_ADD, CAPNG_INHERITABLE, cap);
if (rc) {
printf("Cannot add inheritable cap\n");
exit(2);
}
capng_apply(CAPNG_SELECT_CAPS);
/* Note the two 0s at the end. Kernel checks for these */
if (prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, cap, 0, 0)) {
perror("Cannot set cap");
exit(1);
}
}
int main(int argc, char **argv)
{
int rc;
set_ambient_cap(CAP_NET_RAW);
set_ambient_cap(CAP_NET_ADMIN);
set_ambient_cap(CAP_SYS_NICE);
printf("Ambient_test forking shell\n");
if (execv(argv[1], argv + 1))
perror("Cannot exec");
return 0;
}
Signed-off-by: Christoph Lameter <cl@linux.com> # Original author
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Aaron Jones <aaronmdjones@gmail.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Andrew G. Morgan <morgan@kernel.org>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Markku Savela <msa@moth.iki.fi>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: James Morris <james.l.morris@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 58319057b7847667f0c9585b9de0e8932b0fdb08)
Bug: 31038224
Change-Id: I88bc5caa782dc6be23dc7e839ff8e11b9a903f8c
Signed-off-by: Jorge Lucangeli Obes <jorgelo@google.com>
(cherry pick from 572b57fc6f7fb6ffaa979d505ec2b0a9e9840cca)
Use wake_up_interruptible_sync() to hint to the scheduler binder
transactions are synchronous wakeups. Disable preemption while waking
to avoid ping-ponging on the binder lock.
Signed-off-by: Riley Andrews <riandrews@google.com>
Bug: 30141999
Change-Id: If570d94ef3fed09c328052922d5a9e83d7ba479a
The binder allocator assumes that the thread that
called binder_open will never die for the lifetime of
that proc. That thread is normally the group_leader,
however it may not be. Use the group_leader instead
of current.
Bug: 35707103
Test: Created test case to open with temporary thread
Change-Id: Id693f74b3591f3524a8c6e9508e70f3e5a80c588
Signed-off-by: Todd Kjos <tkjos@google.com>
There's one point was missed in the patch commit da49889deb34 ("staging:
binder: Support concurrent 32 bit and 64 bit processes."). When configure
BINDER_IPC_32BIT, the size of binder_uintptr_t was 32bits, but size of
void * is 64bit on 64bit system. Correct it here.
Signed-off-by: Lisa Du <cldu@marvell.com>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Fixes: da49889deb34 ("staging: binder: Support concurrent 32 bit and 64 bit processes.")
Cc: <stable@vger.kernel.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7a64cd887fdb97f074c3fda03bee0bfb9faceac3)
BUG=b:26833439
TEST=See b:26833439 comment #22
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Change-Id: I204b074fd8cad74cfbeaf322fcdc976877736396
To keep the driver consistent, and until we have
fine-grained locking in place.
Change-Id: Idda7ae8df889b5fae5e96bf343ab17782b4c46b1
Signed-off-by: Martijn Coenen <maco@android.com>
This patch introduces a new binder_fd_array object,
that allows us to support one or more file descriptors
embedded in a buffer that is scatter-gathered.
Change-Id: I647a53cf0d905c7be0dfd9333806982def68dd74
Signed-off-by: Martijn Coenen <maco@google.com>
Previously all data passed over binder needed
to be serialized, with the exception of Binder
objects and file descriptors.
This patchs adds support for scatter-gathering raw
memory buffers into a binder transaction, avoiding
the need to first serialize them into a Parcel.
To remain backwards compatibile with existing
binder clients, it introduces two new command
ioctls for this purpose - BC_TRANSACTION_SG and
BC_REPLY_SG. These commands may only be used with
the new binder_transaction_data_sg structure,
which adds a field for the total size of the
buffers we are scatter-gathering.
Because memory buffers may contain pointers to
other buffers, we allow callers to specify
a parent buffer and an offset into it, to indicate
this is a location pointing to the buffer that
we are fixing up. The kernel will then take care
of fixing up the pointer to that buffer as well.
Change-Id: I02417f28cff14688f2e1d6fcb959438fd96566cc
Signed-off-by: Martijn Coenen <maco@google.com>
The binder_buffer allocator currently only allocates
space for the data and offsets buffers of a Parcel.
This change allows for requesting an additional chunk
of data in the buffer, which can for example be used
to hold additional meta-data about the transaction
(eg a security context).
Change-Id: I58ab9c383a2e1a3057aae6adaa596ce867f1b157
Signed-off-by: Martijn Coenen <maco@google.com>
Moved handling of fixup for binder objects,
handles and file descriptors into separate
functions.
Change-Id: If6849f1caee3834aa87d0ab08950bb1e21ec6e38
Signed-off-by: Martijn Coenen <maco@google.com>
Add a new module parameter 'devices', that can be
used to specify the names of the binder device
nodes we want to populate in /dev.
Each device node has its own context manager, and
is therefore logically separated from all the other
device nodes.
The config option CONFIG_ANDROID_BINDER_DEVICES can
be used to set the default value of the parameter.
This approach was favored over using IPC namespaces,
mostly because we require a single process to be a
part of multiple binder contexts, which seemed harder
to achieve with namespaces.
Change-Id: I3df72b2a19b5ad5a0360e6322482db7b00a12b24
Signed-off-by: Martijn Coenen <maco@google.com>
Move the context manager state into a separate
struct context, and allow for each process to have
its own context associated with it.
Change-Id: Ifa934370241a2d447dd519eac3fd0682c6d00ab4
Signed-off-by: Martijn Coenen <maco@google.com>
Add security hooks to the binder and implement the hooks for SELinux.
The security hooks enable security modules such as SELinux to implement
controls over binder IPC. The security hooks include support for
controlling what process can become the binder context manager
(binder_set_context_mgr), controlling the ability of a process
to invoke a binder transaction/IPC to another process (binder_transaction),
controlling the ability a process to transfer a binder reference to
another process (binder_transfer_binder), and controlling the ability
of a process to transfer an open file to another process (binder_transfer_file).
This support is used by SE Android, http://selinuxproject.org/page/SEAndroid.
Change-Id: I34266b66320b6a3df9ac01833d7f94daf742920e
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
flat_binder_object is used for both handling
binder objects and file descriptors, even though
the two are mostly independent. Since we'll
have more fixup objects in binder in the future,
instead of extending flat_binder_object again,
split out file descriptors to their own object
while retaining backwards compatibility to
existing user-space clients. All binder objects
just share a header.
Change-Id: If3c55f27a2aa8f21815383e0e807be47895e4786
Signed-off-by: Martijn Coenen <maco@google.com>
Issue:
i2c_reg_tbl may be null under error condition when set param.
then, other actuator function still may use the i2c_reg_tbl as null.
Fix:
1) the assignment total_steps follow on kmalloc buffer.
2) Add NULL pointer check for i2c tbl.
CRs-Fixed: 2152401
Change-Id: Ieec3d88e6dae0177787da0906f53d59ac4f5a624
Signed-off-by: Haibin Liu <haibinl@codeaurora.org>
Signed-off-by: VijayaKumar T M <vtmuni@codeaurora.org>
In addition to emulating CNTPCT access, emulate CNTVCT access
too, so that userspace can get CNTVCT value, if the direct
counter read is disabled. Also, keep direct access disabled
by default for userspace.
Change-Id: I70263c129386314880cb28d1e561146ce62d52b8
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Disable user access to physical counter. This reverts
commit 63cb2598d5ba ("clocksource: arch_timer: Enable
user access to the physical counter").
This could potentially break the userspace applications
using physical counters; but all those usages should
move to using virtual counter, to get the timing
information.
Change-Id: I653816a93515507a400ff23dbaa4442bf614a79b
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
As the length datatype is signed, an attacker can both overflow
the calculation or supply a negative number to trick the check
into returning an chosen chunk. This can have undesired
consequences. Always use unsigned integer types for length
values.
Change-Id: Ifde2f0d35129014b976507f7723a319c53fabddf
Acked-by: Thyagarajan Venkatanarayanan <venkatan@qti.qualcomm.com>
Signed-off-by: Tharun Kumar Merugu <mtharu@codeaurora.org>
The list_for_each macro was not used correctly, where the intermediate
variable would be LIST_POISON, resulting in a untrusted pointer
dereference. Switch to using list_for_each_entry_safe to for safe
removal of a list entry.
Change-Id: I0e0fd5dd9f251b5093d6e9d6335387512ec59249
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
Cleanup ION cache maintenance code to properly validate the target of
userspace cache maintenance requests.
Change-Id: I55b8e3584c59634f95250bc7c0bce5d8d70e6a13
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
commit bf33f87dd04c371ea33feb821b60d63d754e3124 upstream.
The user can control the size of the next command passed along, but the
value passed to the ioctl isn't checked against the usable max command
size.
Change-Id: Ib063fb80955665638b3e402993cbbd8c41932fac
Signed-off-by: Peter Chang <dpf@google.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: bf33f87dd04c371ea33feb821b60d63d754e3124
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
- remove the 16 byte CDB (SCSI command) length limit from the sg driver
by handling longer CDBs the same way as the bsg driver. Remove comment
from sg.h public interface about the cmd_len field being limited to 16
bytes.
- remove some dead code caused by this change
- cleanup comment block at the top of sg.h, fix urls
Change-Id: I4152a4ebb8c17140bf47e61a8b5b906e9ec4d945
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Git-commit: 65c26a0f39695ba01d9693754f27ca76cc8a3ab5
Git-repo: https://android.googlesource.com/kernel/msm
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
When getting string from userspace by simple_write_to_buffer
in ufs_qcom_dbg_testbus_cfg_write() function, null byte may
be written out of bounds of configuration buffer if return
value is same as size of buffer, causing off-by-one bug.
This change passes correct available size of configuration
buffer to simple_write_to_buffer function.
Change-Id: I99d4223ba7ac191e7a931c1c0c7be8bcda6263a6
CRs-Fixed: 2143495
Signed-off-by: Yasir Malik <ymalik@codeaurora.org>
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
We now trap accesses to CNTVCT_EL0 when the counter is broken
enough to require the kernel to mediate the access. But it
turns out that some existing userspace (such as OpenMPI) do
probe for the counter frequency, leading to an UNDEF exception
as CNTVCT_EL0 and CNTFRQ_EL0 share the same control bit.
The fix is to handle the exception the same way we do for CNTVCT_EL0.
Fixes: a86bd139f2ae ("arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled")
Reported-by: Hanjun Guo <guohanjun@huawei.com>
Tested-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit 9842119a238bfb92cbab63258dabb54f0e7b111b)
Change-Id: Ie5a9a93fcca238d6097ecacd6df0e540be90220b
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Since people seem to make a point in breaking the userspace visible
counter, we have no choice but to trap the access. Add the required
handler.
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 6126ce0588eb5a0752d5c8b5796a7fca324fd887)
Change-Id: I0705f47c85a78040df38df18f51a4a22500b904d
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Daniel Campello
dookiedude
LuK1337
Tetsuo Handa
Andy Lutomirski
Martijn Coenen
Riley Andrews
Todd Kjos
Lisa Du
Martijn Coenen
Stephen Smalley
VijayaKumar T M
Linux Build Service Account
Bharat Pawar
Linux Build Service Account
Neeraj Upadhyay
Tharun Kumar Merugu
Mahesh Sivasubramanian
Liam Mark
peter chang
Douglas Gilbert
Yasir Malik
Greg Hackmann
Marc Zyngier