24 Jun, 2020
1 commit
-
…inux/kernel/git/powerpc/linux") into android-mainline
Small steps on the way to 5.8-rc1.
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic41e7ca6e9ea1dd506ec44a4251f1ded701efbf6
01 Jun, 2020
1 commit
-
Linux 5.7
Signed-off-by: Greg Kroah-Hartman
Change-Id: I17c5784a03cdbf0df92ce3286abed331881eab94
30 May, 2020
2 commits
-
Move the computation of creds from prepare_binfmt into begin_new_exec
so that the creds need only be computed once. This is just code
reorganization no semantic changes of any kind are made.Moving the computation is safe. I have looked through the kernel and
verified none of the binfmts look at bprm->cred directly, and that
there are no helpers that look at bprm->cred indirectly. Which means
that it is not a problem to compute the bprm->cred later in the
execution flow as it is not used until it becomes current->cred.A new function bprm_creds_from_file is added to contain the work that
needs to be done. bprm_creds_from_file first computes which file
bprm->executable or most likely bprm->file that the bprm->creds
will be computed from.The funciton bprm_fill_uid is updated to receive the file instead of
accessing bprm->file. The now unnecessary work needed to reset the
bprm->cred->euid, and bprm->cred->egid is removed from brpm_fill_uid.
A small comment to document that bprm_fill_uid now only deals with the
work to handle suid and sgid files. The default case is already
heandled by prepare_exec_creds.The function security_bprm_repopulate_creds is renamed
security_bprm_creds_from_file and now is explicitly passed the file
from which to compute the creds. The documentation of the
bprm_creds_from_file security hook is updated to explain when the hook
is called and what it needs to do. The file is passed from
cap_bprm_creds_from_file into get_file_caps so that the caps are
computed for the appropriate file. The now unnecessary work in
cap_bprm_creds_from_file to reset the ambient capabilites has been
removed. A small comment to document that the work of
cap_bprm_creds_from_file is to read capabilities from the files
secureity attribute and derive capabilities from the fact the
user had uid 0 has been added.Reviewed-by: Kees Cook
Signed-off-by: "Eric W. Biederman" -
There is a small bug in the code that recomputes parts of bprm->cred
for every bprm->file. The code never recomputes the part of
clear_dangerous_personality_flags it is responsible for.Which means that in practice if someone creates a sgid script
the interpreter will not be able to use any of:
READ_IMPLIES_EXEC
ADDR_NO_RANDOMIZE
ADDR_COMPAT_LAYOUT
MMAP_PAGE_ZERO.This accentially clearing of personality flags probably does
not matter in practice because no one has complained
but it does make the code more difficult to understand.Further remaining bug compatible prevents the recomputation from being
removed and replaced by simply computing bprm->cred once from the
final bprm->file.Making this change removes the last behavior difference between
computing bprm->creds from the final file and recomputing
bprm->cred several times. Which allows this behavior change
to be justified for it's own reasons, and for any but hunts
looking into why the behavior changed to wind up here instead
of in the code that will follow that computes bprm->cred
from the final bprm->file.This small logic bug appears to have existed since the code
started clearing dangerous personality bits.History Tree: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Fixes: 1bb0fa189c6a ("[PATCH] NX: clean up legacy binary support")
Reviewed-by: Kees Cook
Signed-off-by: "Eric W. Biederman"
28 May, 2020
1 commit
-
This is a bug fix and one of two places where I have found that the
result of calling security_bprm_repopulate_creds more than once on
different bprm->files depends on all of the bprm->files not just the
file bprm->file.I intend to fix both of those cases and then modify the code to
only call security_bprm_repopulate_creds on the final bprm file.So merge this change in so I hopefully reduce conflicts for others
and I make it possible to build on top of this change.Signed-off-by: "Eric W. Biederman"
27 May, 2020
1 commit
-
An invariant of cap_bprm_set_creds is that every field in the new cred
structure that cap_bprm_set_creds might set, needs to be set every
time to ensure the fields does not get a stale value.The field cap_ambient is not set every time cap_bprm_set_creds is
called, which means that if there is a suid or sgid script with an
interpreter that has neither the suid nor the sgid bits set the
interpreter should be able to accept ambient credentials.
Unfortuantely because cap_ambient is not reset to it's original value
the interpreter can not accept ambient credentials.Given that the ambient capability set is expected to be controlled by
the caller, I don't think this is particularly serious. But it is
definitely worth fixing so the code works correctly.I have tested to verify my reading of the code is correct and the
interpreter of a sgid can receive ambient capabilities with this
change and cannot receive ambient capabilities without this change.Cc: stable@vger.kernel.org
Cc: Andy Lutomirski
Fixes: 58319057b784 ("capabilities: ambient capabilities")
Signed-off-by: "Eric W. Biederman"
21 May, 2020
1 commit
-
Rename bprm->cap_elevated to bprm->active_secureexec and initialize it
in prepare_binprm instead of in cap_bprm_set_creds. Initializing
bprm->active_secureexec in prepare_binprm allows multiple
implementations of security_bprm_repopulate_creds to play nicely with
each other.Rename security_bprm_set_creds to security_bprm_reopulate_creds to
emphasize that this path recomputes part of bprm->cred. This
recomputation avoids the time of check vs time of use problems that
are inherent in unix #! interpreters.In short two renames and a move in the location of initializing
bprm->active_secureexec.Link: https://lkml.kernel.org/r/87o8qkzrxp.fsf_-_@x220.int.ebiederm.org
Acked-by: Linus Torvalds
Reviewed-by: Kees Cook
Signed-off-by: "Eric W. Biederman"
06 Nov, 2019
1 commit
-
Add a flag option to get xattr method that could have a bit flag of
XATTR_NOSECURITY passed to it. XATTR_NOSECURITY is generally then
set in the __vfs_getxattr path when called by security
infrastructure.This handles the case of a union filesystem driver that is being
requested by the security layer to report back the xattr data.For the use case where access is to be blocked by the security layer.
The path then could be security(dentry) ->
__vfs_getxattr(dentry...XATTR_NOSECURITY) ->
handler->get(dentry...XATTR_NOSECURITY) ->
__vfs_getxattr(lower_dentry...XATTR_NOSECURITY) ->
lower_handler->get(lower_dentry...XATTR_NOSECURITY)
which would report back through the chain data and success as
expected, the logging security layer at the top would have the
data to determine the access permissions and report back the target
context that was blocked.Without the get handler flag, the path on a union filesystem would be
the errant security(dentry) -> __vfs_getxattr(dentry) ->
handler->get(dentry) -> vfs_getxattr(lower_dentry) -> nested ->
security(lower_dentry, log off) -> lower_handler->get(lower_dentry)
which would report back through the chain no data, and -EACCES.For selinux for both cases, this would translate to a correctly
determined blocked access. In the first case with this change a correct avc
log would be reported, in the second legacy case an incorrect avc log
would be reported against an uninitialized u:object_r:unlabeled:s0
context making the logs cosmetically useless for audit2allow.This patch series is inert and is the wide-spread addition of the
flags option for xattr functions, and a replacement of __vfs_getxattr
with __vfs_getxattr(...XATTR_NOSECURITY).Signed-off-by: Mark Salyzyn
Reviewed-by: Jan Kara
Acked-by: Jan Kara
Acked-by: Jeff Layton
Acked-by: David Sterba
Acked-by: Darrick J. Wong
Acked-by: Mike Marshall
Cc: Stephen Smalley
Cc: linux-kernel@vger.kernel.org
Cc: kernel-team@android.com
Cc: linux-security-module@vger.kernel.org(cherry picked from (rejected from archive because of too many recipients))
Signed-off-by: Mark Salyzyn
Bug: 133515582
Bug: 136124883
Bug: 129319403
Change-Id: Iabbb8771939d5f66667a26bb23ddf4c562c349a1
10 Jul, 2019
1 commit
-
Pull capabilities update from James Morris:
"Minor fixes for capabilities:- Update the commoncap.c code to utilize XATTR_SECURITY_PREFIX_LEN,
from Carmeli tamir.- Make the capability hooks static, from Yue Haibing"
* 'next-lsm' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
security/commoncap: Use xattr security prefix len
security: Make capability_hooks static
07 Jul, 2019
1 commit
-
Using the existing defined XATTR_SECURITY_PREFIX_LEN instead of
sizeof(XATTR_SECURITY_PREFIX) - 1. Pretty simple cleanup.Signed-off-by: Carmeli Tamir
Signed-off-by: James Morris
12 Jun, 2019
1 commit
-
Fix sparse warning:
security/commoncap.c:1347:27: warning:
symbol 'capability_hooks' was not declared. Should it be static?Reported-by: Hulk Robot
Signed-off-by: YueHaibing
Signed-off-by: James Morris
31 May, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later versionextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman
08 Mar, 2019
1 commit
-
Pull audit updates from Paul Moore:
"A lucky 13 audit patches for v5.1.Despite the rather large diffstat, most of the changes are from two
bug fix patches that move code from one Kconfig option to another.Beyond that bit of churn, the remaining changes are largely cleanups
and bug-fixes as we slowly march towards container auditing. It isn't
all boring though, we do have a couple of new things: file
capabilities v3 support, and expanded support for filtering on
filesystems to solve problems with remote filesystems.All changes pass the audit-testsuite. Please merge for v5.1"
* tag 'audit-pr-20190305' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit:
audit: mark expected switch fall-through
audit: hide auditsc_get_stamp and audit_serial prototypes
audit: join tty records to their syscall
audit: remove audit_context when CONFIG_ AUDIT and not AUDITSYSCALL
audit: remove unused actx param from audit_rule_match
audit: ignore fcaps on umount
audit: clean up AUDITSYSCALL prototypes and stubs
audit: more filter PATH records keyed on filesystem magic
audit: add support for fcaps v3
audit: move loginuid and sessionid from CONFIG_AUDITSYSCALL to CONFIG_AUDIT
audit: add syscall information to CONFIG_CHANGE records
audit: hand taken context to audit_kill_trees for syscall logging
audit: give a clue what CONFIG_CHANGE op was involved
26 Feb, 2019
1 commit
-
This should have gone in with commit
c1a85a00ea66cb6f0bd0f14e47c28c2b0999799f.Signed-off-by: Micah Morton
Signed-off-by: James Morris
26 Jan, 2019
1 commit
-
V3 namespaced file capabilities were introduced in
commit 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")Add support for these by adding the "frootid" field to the existing
fcaps fields in the NAME and BPRM_FCAPS records.Please see github issue
https://github.com/linux-audit/audit-kernel/issues/103Signed-off-by: Richard Guy Briggs
Acked-by: Serge Hallyn
[PM: comment tweak to fit an 80 char line width]
Signed-off-by: Paul Moore
11 Jan, 2019
1 commit
-
This patch provides a general mechanism for passing flags to the
security_capable LSM hook. It replaces the specific 'audit' flag that is
used to tell security_capable whether it should log an audit message for
the given capability check. The reason for generalizing this flag
passing is so we can add an additional flag that signifies whether
security_capable is being called by a setid syscall (which is needed by
the proposed SafeSetID LSM).Signed-off-by: Micah Morton
Reviewed-by: Kees Cook
Signed-off-by: James Morris
09 Jan, 2019
1 commit
-
This converts capabilities to use the new LSM_ORDER_FIRST position.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
13 Dec, 2018
1 commit
-
Historically a lot of these existed because we did not have
a distinction between what was modular code and what was providing
support to modules via EXPORT_SYMBOL and friends. That changed
when we forked out support for the latter into the export.h file.
This means we should be able to reduce the usage of module.h
in code that is obj-y Makefile or bool Kconfig.The advantage in removing such instances is that module.h itself
sources about 15 other headers; adding significantly to what we feed
cpp, and it can obscure what headers we are effectively using.Since module.h might have been the implicit source for init.h
(for __init) and for export.h (for EXPORT_SYMBOL) we consider each
instance for the presence of either and replace as needed.Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: John Johansen
Cc: Mimi Zohar
Cc: Dmitry Kasatkin
Cc: David Howells
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Cc: keyrings@vger.kernel.org
Signed-off-by: Paul Gortmaker
Signed-off-by: James Morris
05 Sep, 2018
1 commit
-
Sync to Linux 4.19-rc2 for downstream developers.
30 Aug, 2018
1 commit
-
bprm_caps_from_vfs_caps() never returned -EINVAL so remove the
rc == -EINVAL check.Signed-off-by: Christian Brauner
Reviewed-by: Serge Hallyn
Signed-off-by: James Morris
11 Aug, 2018
1 commit
-
The code in cap_inode_getsecurity(), introduced by commit 8db6c34f1dbc
("Introduce v3 namespaced file capabilities"), should use
d_find_any_alias() instead of d_find_alias() do handle unhashed dentry
correctly. This is needed, for example, if execveat() is called with an
open but unlinked overlayfs file, because overlayfs unhashes dentry on
unlink.
This is a regression of real life application, first reported at
https://www.spinics.net/lists/linux-unionfs/msg05363.htmlBelow reproducer and setup can reproduce the case.
const char* exec="echo";
const char *newargv[] = { "echo", "hello", NULL};
const char *newenviron[] = { NULL };
int fd, err;fd = open(exec, O_PATH);
unlink(exec);
err = syscall(322/*SYS_execveat*/, fd, "", newargv, newenviron,
AT_EMPTY_PATH);
if(err
Acked-by: Amir Goldstein
Acked-by: Serge E. Hallyn
Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
Cc: # v4.14
Signed-off-by: Eddie Horng
Signed-off-by: Eric W. Biederman
25 May, 2018
1 commit
-
A privileged user in s_user_ns will generally have the ability to
manipulate the backing store and insert security.* xattrs into
the filesystem directly. Therefore the kernel must be prepared to
handle these xattrs from unprivileged mounts, and it makes little
sense for commoncap to prevent writing these xattrs to the
filesystem. The capability and LSM code have already been updated
to appropriately handle xattrs from unprivileged mounts, so it
is safe to loosen this restriction on setting xattrs.The exception to this logic is that writing xattrs to a mounted
filesystem may also cause the LSM inode_post_setxattr or
inode_setsecurity callbacks to be invoked. SELinux will deny the
xattr update by virtue of applying mountpoint labeling to
unprivileged userns mounts, and Smack will deny the writes for
any user without global CAP_MAC_ADMIN, so loosening the
capability check in commoncap is safe in this respect as well.Signed-off-by: Seth Forshee
Acked-by: Serge Hallyn
Acked-by: Christian Brauner
Signed-off-by: Eric W. Biederman
11 Apr, 2018
1 commit
-
syzbot is reporting NULL pointer dereference at xattr_getsecurity() [1],
for cap_inode_getsecurity() is returning sizeof(struct vfs_cap_data) when
memory allocation failed. Return -ENOMEM if memory allocation failed.[1] https://syzkaller.appspot.com/bug?id=a55ba438506fe68649a5f50d2d82d56b365e0107
Signed-off-by: Tetsuo Handa
Fixes: 8db6c34f1dbc8e06 ("Introduce v3 namespaced file capabilities")
Reported-by: syzbot
Cc: stable # 4.14+
Acked-by: Serge E. Hallyn
Acked-by: James Morris
Signed-off-by: Eric W. Biederman
02 Jan, 2018
1 commit
-
If userspace attempted to set a "security.capability" xattr shorter than
4 bytes (e.g. 'setfattr -n security.capability -v x file'), then
cap_convert_nscap() read past the end of the buffer containing the xattr
value because it accessed the ->magic_etc field without verifying that
the xattr value is long enough to contain that field.Fix it by validating the xattr value size first.
This bug was found using syzkaller with KASAN. The KASAN report was as
follows (cleaned up slightly):BUG: KASAN: slab-out-of-bounds in cap_convert_nscap+0x514/0x630 security/commoncap.c:498
Read of size 4 at addr ffff88002d8741c0 by task syz-executor1/2852CPU: 0 PID: 2852 Comm: syz-executor1 Not tainted 4.15.0-rc6-00200-gcc0aac99d977 #253
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0xe3/0x195 lib/dump_stack.c:53
print_address_description+0x73/0x260 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x235/0x350 mm/kasan/report.c:409
cap_convert_nscap+0x514/0x630 security/commoncap.c:498
setxattr+0x2bd/0x350 fs/xattr.c:446
path_setxattr+0x168/0x1b0 fs/xattr.c:472
SYSC_setxattr fs/xattr.c:487 [inline]
SyS_setxattr+0x36/0x50 fs/xattr.c:483
entry_SYSCALL_64_fastpath+0x18/0x85Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
Cc: # v4.14+
Signed-off-by: Eric Biggers
Reviewed-by: Serge Hallyn
Signed-off-by: James Morris
14 Nov, 2017
1 commit
-
Pull general security subsystem updates from James Morris:
"TPM (from Jarkko):
- essential clean up for tpm_crb so that ARM64 and x86 versions do
not distract each other as much as before- /dev/tpm0 rejects now too short writes (shorter buffer than
specified in the command header- use DMA-safe buffer in tpm_tis_spi
- otherwise mostly minor fixes.
Smack:
- base support for overlafsCapabilities:
- BPRM_FCAPS fixes, from Richard Guy Briggs:The audit subsystem is adding a BPRM_FCAPS record when auditing
setuid application execution (SYSCALL execve). This is not expected
as it was supposed to be limited to when the file system actually
had capabilities in an extended attribute. It lists all
capabilities making the event really ugly to parse what is
happening. The PATH record correctly records the setuid bit and
owner. Suppress the BPRM_FCAPS record on set*id.TOMOYO:
- Y2038 timestamping fixes"* 'next-general' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (28 commits)
MAINTAINERS: update the IMA, EVM, trusted-keys, encrypted-keys entries
Smack: Base support for overlayfs
MAINTAINERS: remove David Safford as maintainer for encrypted+trusted keys
tomoyo: fix timestamping for y2038
capabilities: audit log other surprising conditions
capabilities: fix logic for effective root or real root
capabilities: invert logic for clarity
capabilities: remove a layer of conditional logic
capabilities: move audit log decision to function
capabilities: use intuitive names for id changes
capabilities: use root_priveleged inline to clarify logic
capabilities: rename has_cap to has_fcap
capabilities: intuitive names for cap gain status
capabilities: factor out cap_bprm_set_creds privileged root
tpm, tpm_tis: use ARRAY_SIZE() to define TPM_HID_USR_IDX
tpm: fix duplicate inline declaration specifier
tpm: fix type of a local variables in tpm_tis_spi.c
tpm: fix type of a local variable in tpm2_map_command()
tpm: fix type of a local variable in tpm2_get_cc_attrs_tbl()
tpm-dev-common: Reject too short writes
...
20 Oct, 2017
10 commits
-
The existing condition tested for process effective capabilities set by
file attributes but intended to ignore the change if the result was
unsurprisingly an effective full set in the case root is special with a
setuid root executable file and we are root.Stated again:
- When you execute a setuid root application, it is no surprise and
expected that it got all capabilities, so we do not want capabilities
recorded.
if (pE_grew && !(pE_fullset && (eff_root || real_root) && root_priveleged) )Now make sure we cover other cases:
- If something prevented a setuid root app getting all capabilities and
it wound up with one capability only, then it is a surprise and should
be logged. When it is a setuid root file, we only want capabilities
when the process does not get full capabilities..
root_priveleged && setuid_root && !pE_fullset- Similarly if a non-setuid program does pick up capabilities due to
file system based capabilities, then we want to know what capabilities
were picked up. When it has file system based capabilities we want
the capabilities.
!is_setuid && (has_fcap && pP_gained)- If it is a non-setuid file and it gets ambient capabilities, we want
the capabilities.
!is_setuid && pA_gained- These last two are combined into one due to the common first parameter.
Related: https://github.com/linux-audit/audit-kernel/issues/16
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Acked-by: Paul Moore
Signed-off-by: James Morris -
Now that the logic is inverted, it is much easier to see that both real
root and effective root conditions had to be met to avoid printing the
BPRM_FCAPS record with audit syscalls. This meant that any setuid root
applications would print a full BPRM_FCAPS record when it wasn't
necessary, cluttering the event output, since the SYSCALL and PATH
records indicated the presence of the setuid bit and effective root user
id.Require only one of effective root or real root to avoid printing the
unnecessary record.Ref: commit 3fc689e96c0c ("Add audit_log_bprm_fcaps/AUDIT_BPRM_FCAPS")
See: https://github.com/linux-audit/audit-kernel/issues/16Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Acked-by: Paul Moore
Signed-off-by: James Morris -
The way the logic was presented, it was awkward to read and verify.
Invert the logic using DeMorgan's Law to be more easily able to read and
understand.Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
Signed-off-by: James Morris -
Remove a layer of conditional logic to make the use of conditions
easier to read and analyse.Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
Signed-off-by: James Morris -
Move the audit log decision logic to its own function to isolate the
complexity in one place.Suggested-by: Serge Hallyn
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
Signed-off-by: James Morris -
Introduce a number of inlines to make the use of the negation of
uid_eq() easier to read and analyse.Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
Signed-off-by: James Morris -
Introduce inline root_privileged() to make use of SECURE_NONROOT
easier to read.Suggested-by: Serge Hallyn
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
Signed-off-by: James Morris -
Rename has_cap to has_fcap to clarify it applies to file capabilities
since the entire source file is about capabilities.Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
Signed-off-by: James Morris -
Introduce macros cap_gained, cap_grew, cap_full to make the use of the
negation of is_subset() easier to read and analyse.Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
Signed-off-by: James Morris -
Factor out the case of privileged root from the function
cap_bprm_set_creds() to make the latter easier to read and analyse.Suggested-by: Serge Hallyn
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
Signed-off-by: James Morris
19 Oct, 2017
1 commit
-
The pointer fs_ns is assigned from inode->i_ib->s_user_ns before
a null pointer check on inode, hence if inode is actually null we
will get a null pointer dereference on this assignment. Fix this
by only dereferencing inode after the null pointer check on
inode.Detected by CoverityScan CID#1455328 ("Dereference before null check")
Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
Signed-off-by: Colin Ian King
Cc: stable@vger.kernel.org
Acked-by: Serge Hallyn
Signed-off-by: James Morris
25 Sep, 2017
1 commit
-
Pull misc security layer update from James Morris:
"This is the remaining 'general' change in the security tree for v4.14,
following the direct merging of SELinux (+ TOMOYO), AppArmor, and
seccomp.That's everything now for the security tree except IMA, which will
follow shortly (I've been traveling for the past week with patchy
internet)"* 'next-general' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
security: fix description of values returned by cap_inode_need_killpriv
24 Sep, 2017
1 commit
-
cap_inode_need_killpriv returns 1 if security.capability exists and
has a value and inode_killpriv() is required, 0 otherwise. Fix the
description of the return value to reflect this.Signed-off-by: Stefan Berger
Reviewed-by: Serge Hallyn
Signed-off-by: James Morris
12 Sep, 2017
1 commit
-
Pull namespace updates from Eric Biederman:
"Life has been busy and I have not gotten half as much done this round
as I would have liked. I delayed it so that a minor conflict
resolution with the mips tree could spend a little time in linux-next
before I sent this pull request.This includes two long delayed user namespace changes from Kirill
Tkhai. It also includes a very useful change from Serge Hallyn that
allows the security capability attribute to be used inside of user
namespaces. The practical effect of this is people can now untar
tarballs and install rpms in user namespaces. It had been suggested to
generalize this and encode some of the namespace information
information in the xattr name. Upon close inspection that makes the
things that should be hard easy and the things that should be easy
more expensive.Then there is my bugfix/cleanup for signal injection that removes the
magic encoding of the siginfo union member from the kernel internal
si_code. The mips folks reported the case where I had used FPE_FIXME
me is impossible so I have remove FPE_FIXME from mips, while at the
same time including a return statement in that case to keep gcc from
complaining about unitialized variables.I almost finished the work to get make copy_siginfo_to_user a trivial
copy to user. The code is available at:git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git neuter-copy_siginfo_to_user-v3
But I did not have time/energy to get the code posted and reviewed
before the merge window opened.I was able to see that the security excuse for just copying fields
that we know are initialized doesn't work in practice there are buggy
initializations that don't initialize the proper fields in siginfo. So
we still sometimes copy unitialized data to userspace"* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
Introduce v3 namespaced file capabilities
mips/signal: In force_fcr31_sig return in the impossible case
signal: Remove kernel interal si_code magic
fcntl: Don't use ambiguous SIG_POLL si_codes
prctl: Allow local CAP_SYS_ADMIN changing exe_file
security: Use user_namespace::level to avoid redundant iterations in cap_capable()
userns,pidns: Verify the userns for new pid namespaces
signal/testing: Don't look for __SI_FAULT in userspace
signal/mips: Document a conflict with SI_USER with SIGFPE
signal/sparc: Document a conflict with SI_USER with SIGFPE
signal/ia64: Document a conflict with SI_USER with SIGFPE
signal/alpha: Document a conflict with SI_USER for SIGTRAP
02 Sep, 2017
1 commit
-
Root in a non-initial user ns cannot be trusted to write a traditional
security.capability xattr. If it were allowed to do so, then any
unprivileged user on the host could map his own uid to root in a private
namespace, write the xattr, and execute the file with privilege on the
host.However supporting file capabilities in a user namespace is very
desirable. Not doing so means that any programs designed to run with
limited privilege must continue to support other methods of gaining and
dropping privilege. For instance a program installer must detect
whether file capabilities can be assigned, and assign them if so but set
setuid-root otherwise. The program in turn must know how to drop
partial capabilities, and do so only if setuid-root.This patch introduces v3 of the security.capability xattr. It builds a
vfs_ns_cap_data struct by appending a uid_t rootid to struct
vfs_cap_data. This is the absolute uid_t (that is, the uid_t in user
namespace which mounted the filesystem, usually init_user_ns) of the
root id in whose namespaces the file capabilities may take effect.When a task asks to write a v2 security.capability xattr, if it is
privileged with respect to the userns which mounted the filesystem, then
nothing should change. Otherwise, the kernel will transparently rewrite
the xattr as a v3 with the appropriate rootid. This is done during the
execution of setxattr() to catch user-space-initiated capability writes.
Subsequently, any task executing the file which has the noted kuid as
its root uid, or which is in a descendent user_ns of such a user_ns,
will run the file with capabilities.Similarly when asking to read file capabilities, a v3 capability will
be presented as v2 if it applies to the caller's namespace.If a task writes a v3 security.capability, then it can provide a uid for
the xattr so long as the uid is valid in its own user namespace, and it
is privileged with CAP_SETFCAP over its namespace. The kernel will
translate that rootid to an absolute uid, and write that to disk. After
this, a task in the writer's namespace will not be able to use those
capabilities (unless rootid was 0), but a task in a namespace where the
given uid is root will.Only a single security.capability xattr may exist at a time for a given
file. A task may overwrite an existing xattr so long as it is
privileged over the inode. Note this is a departure from previous
semantics, which required privilege to remove a security.capability
xattr. This check can be re-added if deemed useful.This allows a simple setxattr to work, allows tar/untar to work, and
allows us to tar in one namespace and untar in another while preserving
the capability, without risking leaking privilege into a parent
namespace.Example using tar:
$ cp /bin/sleep sleepx
$ mkdir b1 b2
$ lxc-usernsexec -m b:0:100000:1 -m b:1:$(id -u):1 -- chown 0:0 b1
$ lxc-usernsexec -m b:0:100001:1 -m b:1:$(id -u):1 -- chown 0:0 b2
$ lxc-usernsexec -m b:0:100000:1000 -- tar --xattrs-include=security.capability --xattrs -cf b1/sleepx.tar sleepx
$ lxc-usernsexec -m b:0:100001:1000 -- tar --xattrs-include=security.capability --xattrs -C b2 -xf b1/sleepx.tar
$ lxc-usernsexec -m b:0:100001:1000 -- getcap b2/sleepx
b2/sleepx = cap_sys_admin+ep
# /opt/ltp/testcases/bin/getv3xattr b2/sleepx
v3 xattr, rootid is 100001A patch to linux-test-project adding a new set of tests for this
functionality is in the nsfscaps branch at github.com/hallyn/ltpChangelog:
Nov 02 2016: fix invalid check at refuse_fcap_overwrite()
Nov 07 2016: convert rootid from and to fs user_ns
(From ebiederm: mar 28 2017)
commoncap.c: fix typos - s/v4/v3
get_vfs_caps_from_disk: clarify the fs_ns root access check
nsfscaps: change the code split for cap_inode_setxattr()
Apr 09 2017:
don't return v3 cap for caps owned by current root.
return a v2 cap for a true v2 cap in non-init ns
Apr 18 2017:
. Change the flow of fscap writing to support s_user_ns writing.
. Remove refuse_fcap_overwrite(). The value of the previous
xattr doesn't matter.
Apr 24 2017:
. incorporate Eric's incremental diff
. move cap_convert_nscap to setxattr and simplify its usage
May 8, 2017:
. fix leaking dentry refcount in cap_inode_getsecuritySigned-off-by: Serge Hallyn
Signed-off-by: Eric W. Biederman
