zfsdev_ioctl skips secpolicy when FKIOCTL is set
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.
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.
Updated by Electric Monk about 4 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 45b1747515a17db45e8971501ee84a26bdff37b2 Author: Alex Wilson <email@example.com> Date: 2016-05-31T18:56:33.000Z 7019 zfsdev_ioctl skips secpolicy when FKIOCTL is set 7020 sdev_cleandir can loop forever Reviewed by: Robert Mustacchi <firstname.lastname@example.org> Reviewed by: Richard Lowe <email@example.com> Reviewed by: Matthew Ahrens <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>