summaryrefslogtreecommitdiffstats
path: root/contrib/diff/src
diff options
context:
space:
mode:
authormav <mav@FreeBSD.org>2016-10-11 16:50:45 +0000
committermav <mav@FreeBSD.org>2016-10-11 16:50:45 +0000
commit6ffd7aae1ea03e042808a353ebc60bc09741acdd (patch)
tree5a9f514940621bf0ecbc5bb7e4215e5a4fa91193 /contrib/diff/src
parent75f8d3771b27068f25a2a620cf959e0af83df24d (diff)
downloadFreeBSD-src-6ffd7aae1ea03e042808a353ebc60bc09741acdd.zip
FreeBSD-src-6ffd7aae1ea03e042808a353ebc60bc09741acdd.tar.gz
MFC r305199: MFV r302648: 7019 zfsdev_ioctl skips secpolicy when FKIOCTL is set
Note that the bulk of the upstream change is not applicable to FreeBSD and the affected files are not even in the vendor area. illumos/illumos-gate@45b1747515a17db45e8971501ee84a26bdff37b2 https://github.com/illumos/illumos-gate/commit/45b1747515a17db45e8971501ee84a26bdff37b2 https://www.illumos.org/issues/7019 Currently zfsdev_ioctl, when confronted by a request with the FKIOCTL flag set, skips all processing of secpolicy functions. This means that ZFS is not doing any kind of verification of the credentials or access rights of the caller and assuming that (as it is an in-kernel client) all such checks have already been done. This turns out to be quite a dangerous assumption, especially with respect to sdev. In general I don't think it's particularly reasonable to offload this enforcement of access rights onto other kernel subsystems when ZFS has some particular local semantics in this area (delegated datasets etc) and does not provide any kind of API to allow other subsystems to avoid code duplication when doing it. ZFS should apply its normal access policy to requests from within the kernel, and callers should take care to give it the correct credentials and call it from the correct context in order to get the results they need. You can observe the currently unfortunate consequences of this bug in any non- global zone that has access to /dev/zvol or any subset of it via sdev profiles. In particular, a zone used to contain a KVM or similar which has a single zvol passed through to it using a <device match= block in its zone XML. Even though sdev makes something of an attempt to control for whether the caller should have access to nodes in /dev/zvol, it doesn't do this correctly, or really at all in the lookup call path. So, if we have a zone that's been given access to any part of /dev/zvol, it can simply look up the full path to any other zvol on the entire system, and the node will appear and be able to be used. Reviewed by: Robert Mustacchi <rm@joyent.com> Reviewed by: Richard Lowe <richlowe@richlowe.net> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Alex Wilson <alex.wilson@joyent.com>
Diffstat (limited to 'contrib/diff/src')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud