Hi,
Thinking more about this, this first step is too restrictive, which
might lead to dangerous situations.
My main concern is that this approach will deny innocuous or even "good"
IOCTL. For instance, if FIOCLEX is denied, this could leak file
descriptors and then introduce vulnerabilities.
As we discussed before, we cannot categorize all IOCTLs, but I think we
need to add exceptions for a subset of them, and maintain this list.
SELinux has some special handling within selinux_file_ioctl(), and we
should use that as a starting point. The do_vfs_ioctl() function is
another important place to look at. The main thing to keep in mind is
that Landlock's goal is to restrict access to data (e.g. FS, network,
IPC, bypass through other processes), not to restrict innocuous (at
least in theory) kernel features.
I think, at least all IOCTLs targeting file descriptors themselves
should always be allowed, similar to fcntl(2)'s F_SETFD and F_SETFL
commands:
- FIOCLEX
- FIONCLEX
- FIONBIO
- FIOASYNC
Some others may not be a good idea:
- FIONREAD should be OK in theory but the VFS part only target regular
files and there is no access check according to the read right, which is
weird.
- FICLONE, FICLONERANGE, FIDEDUPRANGE: read/write actions.
We should add a built-time or run-time safeguard to be sure that future
FD IOCTLs will be added to this list. I'm not sure how to efficiently
implement such protection though.
I'm also wondering if we should not split the IOCTL access right into
three: mostly read, mostly write, and misc. _IOC_READ and _IOC_WRITE are
definitely not perfect, but tied to specific drivers (i.e. not a file
hierarchy but a block or character device) this might help until we get
a more fine-grained IOCTL access control. We should check if it's worth
it according to commonly used drivers. Looking at the TTY driver, most
IOCTLs are without read or write markers. Using this split could induce
a false sense of security, so it should be well motivated.
On 23/06/2023 16:43, Günther Noack wrote:
Hello!
These patches add simple ioctl(2) support to Landlock.
Objective ~~~~~~~~~
Make ioctl(2) requests restrictable with Landlock, in a way that is
useful for real-world applications.
Proposed approach ~~~~~~~~~~~~~~~~~
Introduce the LANDLOCK_ACCESS_FS_IOCTL right, which restricts the
use of ioctl(2) on file descriptors.
We attach the LANDLOCK_ACCESS_FS_IOCTL right to opened file
descriptors, as we already do for LANDLOCK_ACCESS_FS_TRUNCATE.
I believe that this approach works for the majority of use cases,
and offers a good trade-off between Landlock API and implementation
complexity and flexibility when the feature is used.
Current limitations ~~~~~~~~~~~~~~~~~~~
With this patch set, ioctl(2) requests can *not* be filtered based
on file type, device number (dev_t) or on the ioctl(2) request
number.
On the initial RFC patch set [1], we have reached consensus to start
with this simpler coarse-grained approach, and build additional ioctl
restriction capabilities on top in subsequent steps.
[1]
https://lore.kernel.org/linux-security-module/d4f1395c-d2d4-1860-3a02-2a0c023dd761@xxxxxxxxxxx/
Notable implications of this approach
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Existing inherited file descriptors stay unaffected when a program
enables Landlock.
This means in particular that in common scenarios, the terminal's
ioctls (ioctl_tty(2)) continue to work.
* ioctl(2) continues to be available for file descriptors acquired
through means other than open(2). Example: Network sockets,
memfd_create(2), file descriptors that are already open before the
Landlock ruleset is enabled.
Examples ~~~~~~~~
Starting a sandboxed shell from $HOME with
samples/landlock/sandboxer:
LL_FS_RO=/ LL_FS_RW=. ./sandboxer /bin/bash
The LANDLOCK_ACCESS_FS_IOCTL right is part of the "read-write"
rights here, so we expect that newly opened files outside of $HOME
don't work with ioctl(2).
* "stty" works: It probes terminal properties
* "stty </dev/tty" fails: /dev/tty can be reopened, but the ioctl is
denied.
* "eject" fails: ioctls to use CD-ROM drive are denied.
* "ls /dev" works: It uses ioctl to get the terminal size for
columnar layout
* The text editors "vim" and "mg" work. (GNU Emacs fails because it
attempts to reopen /dev/tty.)
Related Work ~~~~~~~~~~~~
OpenBSD's pledge(2) [2] restricts ioctl(2) independent of the file
descriptor which is used. The implementers maintain multiple
allow-lists of predefined ioctl(2) operations required for different
application domains such as "audio", "bpf", "tty" and "inet".
OpenBSD does not guarantee ABI backwards compatibility to the same
extent as Linux does, so it's easier for them to update these lists
in later versions. It might not be a feasible approach for Linux
though.
[2] https://man.openbsd.org/OpenBSD-7.3/pledge.2
Changes ~~~~~~~
V2: * rebased on mic-next * added documentation * exercise ioctl in
the memfd test * test: Use layout0 for the test
---
V1:
https://lore.kernel.org/linux-security-module/20230502171755.9788-1-gnoack3000@xxxxxxxxx/
Günther Noack (6): landlock: Increment Landlock ABI version to 4
landlock: Add LANDLOCK_ACCESS_FS_IOCTL access right
selftests/landlock: Test ioctl support selftests/landlock: Test ioctl
with memfds samples/landlock: Add support for
LANDLOCK_ACCESS_FS_IOCTL landlock: Document ioctl support
Documentation/userspace-api/landlock.rst | 52 ++++++++-----
include/uapi/linux/landlock.h | 19 +++--
samples/landlock/sandboxer.c | 12 ++-
security/landlock/fs.c | 21 +++++-
security/landlock/limits.h | 2 +-
security/landlock/syscalls.c | 2 +-
tools/testing/selftests/landlock/base_test.c | 2 +-
tools/testing/selftests/landlock/fs_test.c | 77
++++++++++++++++++-- 8 files changed, 149 insertions(+), 38
deletions(-)
base-commit: 35ca4239929737bdc021ee923f97ebe7aff8fcc4
