- 23 Nov, 2016 5 commits
-
-
Luis Henriques authored
Revert "(namespace) Revert "UBUNTU: SAUCE: fs: Allow superblock owner to change ownership of inodes with unmappable ids"" BugLink: https://bugs.launchpad.net/bugs/1644165 This reverts commit 65d51ade. The kernel fix for bug #1634964 breaks LXD userspace, in particular the following commits: ac7f3f73 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383a (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs LXD 2.0.6 will include changes to support these kernel changes, but it isn't available yet on xenial, so for now we just revert these commits. Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Luis Henriques authored
BugLink: https://bugs.launchpad.net/bugs/1644165 This reverts commit 07053c83. The kernel fix for bug #1634964 breaks LXD userspace, in particular the following commits: ac7f3f73 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383a (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs LXD 2.0.6 will include changes to support these kernel changes, but it isn't available yet on xenial, so for now we just revert these commits. Signed-off-by:
-
Luis Henriques authored
BugLink: https://bugs.launchpad.net/bugs/1644165 This reverts commit e47ad83f. The kernel fix for bug #1634964 breaks LXD userspace, in particular the following commits: ac7f3f73 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383a (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs LXD 2.0.6 will include changes to support these kernel changes, but it isn't available yet on xenial, so for now we just revert these commits. Signed-off-by:
-
Luis Henriques authored
BugLink: https://bugs.launchpad.net/bugs/1644165 This reverts commit bd088dae. The kernel fix for bug #1634964 breaks LXD userspace, in particular the following commits: ac7f3f73 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383a (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs LXD 2.0.6 will include changes to support these kernel changes, but it isn't available yet on xenial, so for now we just revert these commits. Signed-off-by:
-
Luis Henriques authored
BugLink: https://bugs.launchpad.net/bugs/1644165 This reverts commit 40ccb4df. The kernel fix for bug #1634964 breaks LXD userspace, in particular the following commits: ac7f3f73 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383a (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs LXD 2.0.6 will include changes to support these kernel changes, but it isn't available yet on xenial, so for now we just revert these commits. Signed-off-by:
-
- 14 Nov, 2016 1 commit
-
-
Luis Henriques authored
Ignore: yes Signed-off-by:
-
- 11 Nov, 2016 6 commits
-
-
Luis Henriques authored
Signed-off-by: -
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1641139Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1641139Signed-off-by:
-
Ubuntu authored
BugLink: http://bugs.launchpad.net/bugs/1641139 Committer: Long Li <longli@microsoft.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1641139Signed-off-by:
-
Long Li authored
BugLink: http://bugs.launchpad.net/bugs/1641139Signed-off-by:
-
- 10 Nov, 2016 2 commits
-
-
Luis Henriques authored
Ignore: yes Signed-off-by: -
Luis Henriques authored
Signed-off-by:
-
- 09 Nov, 2016 3 commits
-
-
Eric W. Biederman authored
BugLink: https://bugs.launchpad.net/bugs/1639345 During exec dumpable is cleared if the file that is being executed is not readable by the user executing the file. A bug in ptrace_may_access allows reading the file if the executable happens to enter into a subordinate user namespace (aka clone(CLONE_NEWUSER), unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER). This problem is fixed with only necessary userspace breakage by adding a user namespace owner to mm_struct, captured at the time of exec, so it is clear in which user namespace CAP_SYS_PTRACE must be present in to be able to safely give read permission to the executable. The function ptrace_may_access is modified to verify that the ptracer has CAP_SYS_ADMIN in task->mm->user_ns instead of task->cred->user_ns. This ensures that if the task changes it's cred into a subordinate user namespace it does not become ptraceable. The function ptrace_attach is modified to only set PT_PTRACE_CAP when CAP_SYS_PTRACE is held over task->mm->user_ns. The intent of PT_PTRACE_CAP is to be a flag to note that whatever permission changes the task might go through the tracer has sufficient permissions for it not to be an issue. task->cred->user_ns is always the same as or descendent of mm->user_ns. Which guarantees that having CAP_SYS_PTRACE over mm->user_ns is the worst case for the tasks credentials. To prevent regressions mm->dumpable and mm->user_ns are not considered when a task has no mm. As simply failing ptrace_may_attach causes regressions in privileged applications attempting to read things such as /proc/<pid>/stat Cc: stable@vger.kernel.org Acked-by:
Kees Cook <keescook@chromium.org> Tested-by:
Cyrill Gorcunov <gorcunov@openvz.org> Fixes: 8409cca7 ("userns: allow ptrace from non-init user namespaces") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> (cherry picked from commit 2e41414828bb0b066bde2f156cfa848c38531edf linux-next) CVE-2015-8709 Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Seth Forshee authored
BugLink: https://bugs.launchpad.net/bugs/1639345 This reverts commit a76b8ce7 to apply a more complete fix from linux-next. CVE-2015-8709 Signed-off-by:
-
Douglas Miller authored
BugLink: http://bugs.launchpad.net/bugs/1637978 Add 'P' command with optional task_struct address to dump all/one task's information: task pointer, kernel stack pointer, PID, PPID, state (interpreted), CPU where (last) running, and command. Signed-off-by:
Douglas Miller <dougmill@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 6dfb5404) Signed-off-by:
-
- 08 Nov, 2016 23 commits
-
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1636517 Xenial kernel commit 193fb6a2c94fab8eb8ce70a5da4d21c7d4023bee ("block_dev: Support checking inode permissions in lookup_bdev()") added a flags argument to block_dev which caused this breakage. Add detection of 1 or 2 arg block_dev and add a zfs_block_dev shim to abstract these differences away. Kudos to Fabian Grünbichler for the original fix that this fix is based on. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Agrawal, Nitesh-kumar authored
The earlier patch can be simplified by using a bool to indicate level trigger. BugLink: http://bugs.launchpad.net/bugs/1612006Reviewed-by:
Pankaj Sen <Pankaj.Sen@amd.com> Signed-off-by:
Nitesh Kumar Agrawal <Nitesh-kumar.Agrawal@amd.com> [Fixup to earlier manually applied patch] Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> (cherry picked from commit e084448b) Signed-off-by:
Alex Hung <alex.hung@canonical.com> Acked-by:
Robert Hooker <robert.hooker@canonical.com> Acked-by:
-
Agrawal, Nitesh-kumar authored
In the function amd_gpio_irq_set_type, use the settings provided by the BIOS,when the LevelTrig is Edge and activeLevel is HIGH, to configure the GPIO registers. Ignore the settings from client. BugLink: http://bugs.launchpad.net/bugs/1612006Reviewed-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1636733Signed-off-by:
-
Paul Mackerras authored
BugLink: http://bugs.launchpad.net/bugs/1630554 As discussed recently on the kvm mailing list, David Gibson's intention in commit 178a7875 ("vfio: Enable VFIO device for powerpc", 2016-02-01) was to have the KVM VFIO device built in on all powerpc platforms. This patch adds the "select KVM_VFIO" statement that makes this happen. Currently, arch/powerpc/kvm/Makefile doesn't include vfio.o for the 64-bit kvm module, because the list of objects doesn't use the $(common-objs-y) list. The reason it doesn't is because we don't necessarily want coalesced_mmio.o or emulate.o (for example if HV KVM is the only target), and common-objs-y includes both. Since this is confusing, this patch adjusts the definitions so that we now use $(common-objs-y) in the list for the 64-bit kvm.ko module, emulate.o is removed from common-objs-y and added in the places that need it, and the inclusion of coalesced_mmio.o now depends on CONFIG_KVM_MMIO. Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> (back ported from commit 4b3d173d) Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Supporting snaps in lxd containers requires mounting filesystems in user namespaces using fuse. Enable this by default, but keep the module parameter to allow users to disable it if desired. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Expand the check in should_remove_suid() to keep privileges for CAP_FSETID in s_user_ns rather than init_user_ns. --EWB Changed from ns_capable(sb->s_user_ns, ) to capable_wrt_inode_uidgid Signed-off-by:
Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit b50099a2 in order to apply the version in yakkety. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Allow users with CAP_SYS_CHOWN over the superblock of a filesystem to chown files. Ordinarily the capable_wrt_inode_uidgid check is sufficient to allow access to files but when the underlying filesystem has uids or gids that don't map to the current user namespace it is not enough, so the chown permission checks need to be extended to allow this case. Calling chown on filesystem nodes whose uid or gid don't map is necessary if those nodes are going to be modified as writing back inodes which contain uids or gids that don't map is likely to cause filesystem corruption of the uid or gid fields. Once chown has been called the existing capable_wrt_inode_uidgid checks are sufficient, to allow the owner of a superblock to do anything the global root user can do with an appropriate set of capabilities. For the proc filesystem this relaxation of permissions is not safe, as some files are owned by users (particularly GLOBAL_ROOT_UID) outside of the control of the mounter of the proc and that would be unsafe to grant chown access to. So update setattr on proc to disallow changing files whose uids or gids are outside of proc's s_user_ns. The original version of this patch was written by: Seth Forshee. I have rewritten and rethought this patch enough so it's really not the same thing (certainly it needs a different description), but he deserves credit for getting out there and getting the conversation started, and finding the potential gotcha's and putting up with my semi-paranoid feedback. Inspired-by:
-
Seth Forshee authored
(namespace) Revert "UBUNTU: SAUCE: fs: Allow superblock owner to change ownership of inodes with unmappable ids" This reverts commit 6e42b32e in order to apply the version in yakkety. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 In general the handling of IMA/EVM xattrs is good, but I found a few locations where either the xattr size or the value of the type field in the xattr are not checked. Add a few simple checks to these locations to prevent malformed or malicious xattrs from causing problems. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 5d96fa44, as it adds attack surface without any clear use case at this point. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Mostly supporting filesystems outside of init_user_ns is s/&init_usre_ns/dquot->dq_sb->s_user_ns/. An actual need for supporting quotas on filesystems outside of s_user_ns is quite a ways away and to be done responsibily needs an audit on what can happen with hostile quota files. Until that audit is complete don't attempt to support quota files on filesystems outside of s_user_ns. Cc: Jan Kara <jack@suse.cz> Acked-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 In Q_XSETQLIMIT use sb->s_user_ns to detect when we are dealing with the filesystems notion of id 0. Cc: Jan Kara <jack@suse.cz> Acked-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Introduce the helper qid_has_mapping and use it to ensure that the quota system only considers qids that map to the filesystems s_user_ns. In practice for quota supporting filesystems today this is the exact same check as qid_valid. As only 0xffffffff aka (qid_t)-1 does not map into init_user_ns. Replace the qid_valid calls with qid_has_mapping as values come in from userspace. This is harmless today and it prepares the quota system to work on filesystems with quotas but mounted by unprivileged users. Call qid_has_mapping from dqget. This ensures the passed in qid has a prepresentation on the underlying filesystem. Previously this was unnecessary as filesystesm never had qids that could not map. With the introduction of filesystems outside of s_user_ns this will not remain true. All of this ensures the quota code never has to deal with qids that don't map to the underlying filesystem. Cc: Jan Kara <jack@suse.cz> Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 95317559 in order to apply the corresponding upstream patches. Signed-off-by:
-
Seth Forshee authored
(namespace) Revert "UBUNTU: SAUCE: quota: Require that qids passed to dqget() be valid and map into s_user_ns" BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 2c79b9bf in order to apply the corresponding upstream patches. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 It is expected that filesystems can not represent uids and gids from outside of their user namespace. Keep things simple by not even trying to create filesystem nodes with non-sense uids and gids. Acked-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 When a filesystem outside of init_user_ns is mounted it could have uids and gids stored in it that do not map to init_user_ns. The plan is to allow those filesystems to set i_uid to INVALID_UID and i_gid to INVALID_GID for unmapped uids and gids and then to handle that strange case in the vfs to ensure there is consistent robust handling of the weirdness. Upon a careful review of the vfs and filesystems about the only case where there is any possibility of confusion or trouble is when the inode is written back to disk. In that case filesystems typically read the inode->i_uid and inode->i_gid and write them to disk even when just an inode timestamp is being updated. Which leads to a rule that is very simple to implement and understand inodes whose i_uid or i_gid is not valid may not be written. In dealing with access times this means treat those inodes as if the inode flag S_NOATIME was set. Reads of the inodes appear safe and useful, but any write or modification is disallowed. The only inode write that is allowed is a chown that sets the uid and gid on the inode to valid values. After such a chown the inode is normal and may be treated as such. Denying all writes to inodes with uids or gids unknown to the vfs also prevents several oddball cases where corruption would have occurred because the vfs does not have complete information. One problem case that is prevented is attempting to use the gid of a directory for new inodes where the directories sgid bit is set but the directories gid is not mapped. Another problem case avoided is attempting to update the evm hash after setxattr, removexattr, and setattr. As the evm hash includeds the inode->i_uid or inode->i_gid not knowning the uid or gid prevents a correct evm hash from being computed. evm hash verification also fails when i_uid or i_gid is unknown but that is essentially harmless as it does not cause filesystem corruption. Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Fuse currently lacks comprehensive support for posix ACLs, but some fuse filesystems process the acl xattrs internally. For this to continue to work the ids within the xattrs need to be mapped into s_user_ns when written to the filesystem and mapped from s_user_ns when read. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Fuse will make use of this function to provide backwards- compatible acl support when proper posix acl support is added. Add a check to return immediately if the to and from namespaces are the same, and remove equivalent checks from its callers. Also return an error code to indicate to callers whether or not the conversion of the id between the user namespaces was successful. For a valid xattr the id will continue to be changed regardless to maintain the current behaviour for existing callers, so they do not require updates to handle failed conversions. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Update posix_acl_valid to verify that an acl is within a user namespace. Update the callers of posix_acl_valid to pass in an appropriate user namespace. For posix_acl_xattr_set and v9fs_xattr_set_acl pass in inode->i_sb->s_user_ns to posix_acl_valid. For md_unpack_acl pass in &init_user_ns as no inode or superblock is in sight. Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 7efdc167 in order to apply the corresponding upstream patch. Signed-off-by:
-
