2021-04-22 15:41:17 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
/*
|
|
|
|
* Landlock LSM - Filesystem management and hooks
|
|
|
|
*
|
|
|
|
* Copyright © 2016-2020 Mickaël Salaün <mic@digikod.net>
|
|
|
|
* Copyright © 2018-2020 ANSSI
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
* Copyright © 2021-2022 Microsoft Corporation
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
* Copyright © 2022 Günther Noack <gnoack3000@gmail.com>
|
|
|
|
* Copyright © 2023-2024 Google LLC
|
2021-04-22 15:41:17 +00:00
|
|
|
*/
|
|
|
|
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
#include <asm/ioctls.h>
|
2024-01-18 11:36:32 +00:00
|
|
|
#include <kunit/test.h>
|
2021-04-22 15:41:17 +00:00
|
|
|
#include <linux/atomic.h>
|
|
|
|
#include <linux/bitops.h>
|
|
|
|
#include <linux/bits.h>
|
|
|
|
#include <linux/compiler_types.h>
|
|
|
|
#include <linux/dcache.h>
|
|
|
|
#include <linux/err.h>
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
#include <linux/falloc.h>
|
2021-04-22 15:41:17 +00:00
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/limits.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/lsm_hooks.h>
|
|
|
|
#include <linux/mount.h>
|
|
|
|
#include <linux/namei.h>
|
|
|
|
#include <linux/path.h>
|
|
|
|
#include <linux/rcupdate.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/stat.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/wait_bit.h>
|
|
|
|
#include <linux/workqueue.h>
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
#include <uapi/linux/fiemap.h>
|
2021-04-22 15:41:17 +00:00
|
|
|
#include <uapi/linux/landlock.h>
|
|
|
|
|
|
|
|
#include "common.h"
|
|
|
|
#include "cred.h"
|
|
|
|
#include "fs.h"
|
|
|
|
#include "limits.h"
|
|
|
|
#include "object.h"
|
|
|
|
#include "ruleset.h"
|
|
|
|
#include "setup.h"
|
|
|
|
|
|
|
|
/* Underlying object management */
|
|
|
|
|
|
|
|
static void release_inode(struct landlock_object *const object)
|
|
|
|
__releases(object->lock)
|
|
|
|
{
|
|
|
|
struct inode *const inode = object->underobj;
|
|
|
|
struct super_block *sb;
|
|
|
|
|
|
|
|
if (!inode) {
|
|
|
|
spin_unlock(&object->lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Protects against concurrent use by hook_sb_delete() of the reference
|
|
|
|
* to the underlying inode.
|
|
|
|
*/
|
|
|
|
object->underobj = NULL;
|
|
|
|
/*
|
|
|
|
* Makes sure that if the filesystem is concurrently unmounted,
|
|
|
|
* hook_sb_delete() will wait for us to finish iput().
|
|
|
|
*/
|
|
|
|
sb = inode->i_sb;
|
|
|
|
atomic_long_inc(&landlock_superblock(sb)->inode_refs);
|
|
|
|
spin_unlock(&object->lock);
|
|
|
|
/*
|
|
|
|
* Because object->underobj was not NULL, hook_sb_delete() and
|
|
|
|
* get_inode_object() guarantee that it is safe to reset
|
|
|
|
* landlock_inode(inode)->object while it is not NULL. It is therefore
|
|
|
|
* not necessary to lock inode->i_lock.
|
|
|
|
*/
|
|
|
|
rcu_assign_pointer(landlock_inode(inode)->object, NULL);
|
|
|
|
/*
|
|
|
|
* Now, new rules can safely be tied to @inode with get_inode_object().
|
|
|
|
*/
|
|
|
|
|
|
|
|
iput(inode);
|
|
|
|
if (atomic_long_dec_and_test(&landlock_superblock(sb)->inode_refs))
|
|
|
|
wake_up_var(&landlock_superblock(sb)->inode_refs);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct landlock_object_underops landlock_fs_underops = {
|
|
|
|
.release = release_inode
|
|
|
|
};
|
|
|
|
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
/* IOCTL helpers */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* is_masked_device_ioctl - Determine whether an IOCTL command is always
|
|
|
|
* permitted with Landlock for device files. These commands can not be
|
|
|
|
* restricted on device files by enforcing a Landlock policy.
|
|
|
|
*
|
|
|
|
* @cmd: The IOCTL command that is supposed to be run.
|
|
|
|
*
|
|
|
|
* By default, any IOCTL on a device file requires the
|
|
|
|
* LANDLOCK_ACCESS_FS_IOCTL_DEV right. However, we blanket-permit some
|
|
|
|
* commands, if:
|
|
|
|
*
|
|
|
|
* 1. The command is implemented in fs/ioctl.c's do_vfs_ioctl(),
|
|
|
|
* not in f_ops->unlocked_ioctl() or f_ops->compat_ioctl().
|
|
|
|
*
|
|
|
|
* 2. The command is harmless when invoked on devices.
|
|
|
|
*
|
|
|
|
* We also permit commands that do not make sense for devices, but where the
|
|
|
|
* do_vfs_ioctl() implementation returns a more conventional error code.
|
|
|
|
*
|
|
|
|
* Any new IOCTL commands that are implemented in fs/ioctl.c's do_vfs_ioctl()
|
|
|
|
* should be considered for inclusion here.
|
|
|
|
*
|
|
|
|
* Returns: true if the IOCTL @cmd can not be restricted with Landlock for
|
|
|
|
* device files.
|
|
|
|
*/
|
|
|
|
static __attribute_const__ bool is_masked_device_ioctl(const unsigned int cmd)
|
|
|
|
{
|
|
|
|
switch (cmd) {
|
|
|
|
/*
|
|
|
|
* FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC manipulate the FD's
|
|
|
|
* close-on-exec and the file's buffered-IO and async flags. These
|
|
|
|
* operations are also available through fcntl(2), and are
|
|
|
|
* unconditionally permitted in Landlock.
|
|
|
|
*/
|
|
|
|
case FIOCLEX:
|
|
|
|
case FIONCLEX:
|
|
|
|
case FIONBIO:
|
|
|
|
case FIOASYNC:
|
|
|
|
/*
|
|
|
|
* FIOQSIZE queries the size of a regular file, directory, or link.
|
|
|
|
*
|
|
|
|
* We still permit it, because it always returns -ENOTTY for
|
|
|
|
* other file types.
|
|
|
|
*/
|
|
|
|
case FIOQSIZE:
|
|
|
|
/*
|
|
|
|
* FIFREEZE and FITHAW freeze and thaw the file system which the
|
|
|
|
* given file belongs to. Requires CAP_SYS_ADMIN.
|
|
|
|
*
|
|
|
|
* These commands operate on the file system's superblock rather
|
|
|
|
* than on the file itself. The same operations can also be
|
|
|
|
* done through any other file or directory on the same file
|
|
|
|
* system, so it is safe to permit these.
|
|
|
|
*/
|
|
|
|
case FIFREEZE:
|
|
|
|
case FITHAW:
|
|
|
|
/*
|
|
|
|
* FS_IOC_FIEMAP queries information about the allocation of
|
|
|
|
* blocks within a file.
|
|
|
|
*
|
|
|
|
* This IOCTL command only makes sense for regular files and is
|
|
|
|
* not implemented by devices. It is harmless to permit.
|
|
|
|
*/
|
|
|
|
case FS_IOC_FIEMAP:
|
|
|
|
/*
|
|
|
|
* FIGETBSZ queries the file system's block size for a file or
|
|
|
|
* directory.
|
|
|
|
*
|
|
|
|
* This command operates on the file system's superblock rather
|
|
|
|
* than on the file itself. The same operation can also be done
|
|
|
|
* through any other file or directory on the same file system,
|
|
|
|
* so it is safe to permit it.
|
|
|
|
*/
|
|
|
|
case FIGETBSZ:
|
|
|
|
/*
|
|
|
|
* FICLONE, FICLONERANGE and FIDEDUPERANGE make files share
|
|
|
|
* their underlying storage ("reflink") between source and
|
|
|
|
* destination FDs, on file systems which support that.
|
|
|
|
*
|
|
|
|
* These IOCTL commands only apply to regular files
|
|
|
|
* and are harmless to permit for device files.
|
|
|
|
*/
|
|
|
|
case FICLONE:
|
|
|
|
case FICLONERANGE:
|
|
|
|
case FIDEDUPERANGE:
|
|
|
|
/*
|
|
|
|
* FS_IOC_GETFSUUID and FS_IOC_GETFSSYSFSPATH both operate on
|
|
|
|
* the file system superblock, not on the specific file, so
|
|
|
|
* these operations are available through any other file on the
|
|
|
|
* same file system as well.
|
|
|
|
*/
|
|
|
|
case FS_IOC_GETFSUUID:
|
|
|
|
case FS_IOC_GETFSSYSFSPATH:
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* FIONREAD, FS_IOC_GETFLAGS, FS_IOC_SETFLAGS, FS_IOC_FSGETXATTR and
|
|
|
|
* FS_IOC_FSSETXATTR are forwarded to device implementations.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* file_ioctl() commands (FIBMAP, FS_IOC_RESVSP, FS_IOC_RESVSP64,
|
|
|
|
* FS_IOC_UNRESVSP, FS_IOC_UNRESVSP64 and FS_IOC_ZERO_RANGE) are
|
|
|
|
* forwarded to device implementations, so not permitted.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Other commands are guarded by the access right. */
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* is_masked_device_ioctl_compat - same as the helper above, but checking the
|
|
|
|
* "compat" IOCTL commands.
|
|
|
|
*
|
|
|
|
* The IOCTL commands with special handling in compat-mode should behave the
|
|
|
|
* same as their non-compat counterparts.
|
|
|
|
*/
|
|
|
|
static __attribute_const__ bool
|
|
|
|
is_masked_device_ioctl_compat(const unsigned int cmd)
|
|
|
|
{
|
|
|
|
switch (cmd) {
|
|
|
|
/* FICLONE is permitted, same as in the non-compat variant. */
|
|
|
|
case FICLONE:
|
|
|
|
return true;
|
|
|
|
|
|
|
|
#if defined(CONFIG_X86_64)
|
|
|
|
/*
|
|
|
|
* FS_IOC_RESVSP_32, FS_IOC_RESVSP64_32, FS_IOC_UNRESVSP_32,
|
|
|
|
* FS_IOC_UNRESVSP64_32, FS_IOC_ZERO_RANGE_32: not blanket-permitted,
|
|
|
|
* for consistency with their non-compat variants.
|
|
|
|
*/
|
|
|
|
case FS_IOC_RESVSP_32:
|
|
|
|
case FS_IOC_RESVSP64_32:
|
|
|
|
case FS_IOC_UNRESVSP_32:
|
|
|
|
case FS_IOC_UNRESVSP64_32:
|
|
|
|
case FS_IOC_ZERO_RANGE_32:
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* FS_IOC32_GETFLAGS, FS_IOC32_SETFLAGS are forwarded to their device
|
|
|
|
* implementations.
|
|
|
|
*/
|
|
|
|
case FS_IOC32_GETFLAGS:
|
|
|
|
case FS_IOC32_SETFLAGS:
|
|
|
|
return false;
|
|
|
|
default:
|
|
|
|
return is_masked_device_ioctl(cmd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-04-22 15:41:17 +00:00
|
|
|
/* Ruleset management */
|
|
|
|
|
|
|
|
static struct landlock_object *get_inode_object(struct inode *const inode)
|
|
|
|
{
|
|
|
|
struct landlock_object *object, *new_object;
|
|
|
|
struct landlock_inode_security *inode_sec = landlock_inode(inode);
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
retry:
|
|
|
|
object = rcu_dereference(inode_sec->object);
|
|
|
|
if (object) {
|
|
|
|
if (likely(refcount_inc_not_zero(&object->usage))) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
return object;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* We are racing with release_inode(), the object is going
|
|
|
|
* away. Wait for release_inode(), then retry.
|
|
|
|
*/
|
|
|
|
spin_lock(&object->lock);
|
|
|
|
spin_unlock(&object->lock);
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there is no object tied to @inode, then create a new one (without
|
|
|
|
* holding any locks).
|
|
|
|
*/
|
|
|
|
new_object = landlock_create_object(&landlock_fs_underops, inode);
|
|
|
|
if (IS_ERR(new_object))
|
|
|
|
return new_object;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Protects against concurrent calls to get_inode_object() or
|
|
|
|
* hook_sb_delete().
|
|
|
|
*/
|
|
|
|
spin_lock(&inode->i_lock);
|
|
|
|
if (unlikely(rcu_access_pointer(inode_sec->object))) {
|
|
|
|
/* Someone else just created the object, bail out and retry. */
|
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
kfree(new_object);
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* @inode will be released by hook_sb_delete() on its superblock
|
|
|
|
* shutdown, or by release_inode() when no more ruleset references the
|
|
|
|
* related object.
|
|
|
|
*/
|
|
|
|
ihold(inode);
|
|
|
|
rcu_assign_pointer(inode_sec->object, new_object);
|
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
return new_object;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* All access rights that can be tied to files. */
|
2022-05-06 16:05:07 +00:00
|
|
|
/* clang-format off */
|
2021-04-22 15:41:17 +00:00
|
|
|
#define ACCESS_FILE ( \
|
|
|
|
LANDLOCK_ACCESS_FS_EXECUTE | \
|
|
|
|
LANDLOCK_ACCESS_FS_WRITE_FILE | \
|
2022-10-18 18:22:09 +00:00
|
|
|
LANDLOCK_ACCESS_FS_READ_FILE | \
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
LANDLOCK_ACCESS_FS_TRUNCATE | \
|
|
|
|
LANDLOCK_ACCESS_FS_IOCTL_DEV)
|
2022-05-06 16:05:07 +00:00
|
|
|
/* clang-format on */
|
2021-04-22 15:41:17 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* @path: Should have been checked by get_path_from_fd().
|
|
|
|
*/
|
|
|
|
int landlock_append_fs_rule(struct landlock_ruleset *const ruleset,
|
2022-05-06 16:10:51 +00:00
|
|
|
const struct path *const path,
|
|
|
|
access_mask_t access_rights)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
|
|
|
int err;
|
2023-10-26 01:47:42 +00:00
|
|
|
struct landlock_id id = {
|
|
|
|
.type = LANDLOCK_KEY_INODE,
|
|
|
|
};
|
2021-04-22 15:41:17 +00:00
|
|
|
|
|
|
|
/* Files only get access rights that make sense. */
|
2022-05-06 16:05:08 +00:00
|
|
|
if (!d_is_dir(path->dentry) &&
|
|
|
|
(access_rights | ACCESS_FILE) != ACCESS_FILE)
|
2021-04-22 15:41:17 +00:00
|
|
|
return -EINVAL;
|
|
|
|
if (WARN_ON_ONCE(ruleset->num_layers != 1))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Transforms relative access rights to absolute ones. */
|
2023-10-26 01:47:40 +00:00
|
|
|
access_rights |= LANDLOCK_MASK_ACCESS_FS &
|
2023-10-26 01:47:41 +00:00
|
|
|
~landlock_get_fs_access_mask(ruleset, 0);
|
2023-10-26 01:47:42 +00:00
|
|
|
id.key.object = get_inode_object(d_backing_inode(path->dentry));
|
|
|
|
if (IS_ERR(id.key.object))
|
|
|
|
return PTR_ERR(id.key.object);
|
2021-04-22 15:41:17 +00:00
|
|
|
mutex_lock(&ruleset->lock);
|
2023-10-26 01:47:42 +00:00
|
|
|
err = landlock_insert_rule(ruleset, id, access_rights);
|
2021-04-22 15:41:17 +00:00
|
|
|
mutex_unlock(&ruleset->lock);
|
|
|
|
/*
|
|
|
|
* No need to check for an error because landlock_insert_rule()
|
|
|
|
* increments the refcount for the new object if needed.
|
|
|
|
*/
|
2023-10-26 01:47:42 +00:00
|
|
|
landlock_put_object(id.key.object);
|
2021-04-22 15:41:17 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Access-control management */
|
|
|
|
|
2022-05-06 16:10:53 +00:00
|
|
|
/*
|
|
|
|
* The lifetime of the returned rule is tied to @domain.
|
|
|
|
*
|
|
|
|
* Returns NULL if no rule is found or if @dentry is negative.
|
|
|
|
*/
|
2023-12-08 15:51:13 +00:00
|
|
|
static const struct landlock_rule *
|
2022-05-06 16:10:53 +00:00
|
|
|
find_rule(const struct landlock_ruleset *const domain,
|
|
|
|
const struct dentry *const dentry)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
|
|
|
const struct landlock_rule *rule;
|
|
|
|
const struct inode *inode;
|
2023-10-26 01:47:42 +00:00
|
|
|
struct landlock_id id = {
|
|
|
|
.type = LANDLOCK_KEY_INODE,
|
|
|
|
};
|
2021-04-22 15:41:17 +00:00
|
|
|
|
2022-05-06 16:10:53 +00:00
|
|
|
/* Ignores nonexistent leafs. */
|
|
|
|
if (d_is_negative(dentry))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
inode = d_backing_inode(dentry);
|
2021-04-22 15:41:17 +00:00
|
|
|
rcu_read_lock();
|
2023-10-26 01:47:42 +00:00
|
|
|
id.key.object = rcu_dereference(landlock_inode(inode)->object);
|
|
|
|
rule = landlock_find_rule(domain, id);
|
2021-04-22 15:41:17 +00:00
|
|
|
rcu_read_unlock();
|
2022-05-06 16:10:53 +00:00
|
|
|
return rule;
|
|
|
|
}
|
|
|
|
|
2022-05-06 16:10:55 +00:00
|
|
|
/*
|
|
|
|
* Allows access to pseudo filesystems that will never be mountable (e.g.
|
|
|
|
* sockfs, pipefs), but can still be reachable through
|
|
|
|
* /proc/<pid>/fd/<file-descriptor>
|
|
|
|
*/
|
2023-12-08 15:51:13 +00:00
|
|
|
static bool is_nouser_or_private(const struct dentry *dentry)
|
2022-05-06 16:10:55 +00:00
|
|
|
{
|
|
|
|
return (dentry->d_sb->s_flags & SB_NOUSER) ||
|
|
|
|
(d_is_positive(dentry) &&
|
|
|
|
unlikely(IS_PRIVATE(d_backing_inode(dentry))));
|
|
|
|
}
|
|
|
|
|
2023-10-26 01:47:41 +00:00
|
|
|
static access_mask_t
|
|
|
|
get_raw_handled_fs_accesses(const struct landlock_ruleset *const domain)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
2023-10-26 01:47:41 +00:00
|
|
|
access_mask_t access_dom = 0;
|
landlock: Fix file reparenting without explicit LANDLOCK_ACCESS_FS_REFER
This change fixes a mis-handling of the LANDLOCK_ACCESS_FS_REFER right
when multiple rulesets/domains are stacked. The expected behaviour was
that an additional ruleset can only restrict the set of permitted
operations, but in this particular case, it was potentially possible to
re-gain the LANDLOCK_ACCESS_FS_REFER right.
With the introduction of LANDLOCK_ACCESS_FS_REFER, we added the first
globally denied-by-default access right. Indeed, this lifted an initial
Landlock limitation to rename and link files, which was initially always
denied when the source or the destination were different directories.
This led to an inconsistent backward compatibility behavior which was
only taken into account if no domain layer were using the new
LANDLOCK_ACCESS_FS_REFER right. However, when restricting a thread with
a new ruleset handling LANDLOCK_ACCESS_FS_REFER, all inherited parent
rulesets/layers not explicitly handling LANDLOCK_ACCESS_FS_REFER would
behave as if they were handling this access right and with all their
rules allowing it. This means that renaming and linking files could
became allowed by these parent layers, but all the other required
accesses must also be granted: all layers must allow file removal or
creation, and renaming and linking operations cannot lead to privilege
escalation according to the Landlock policy. See detailed explanation
in commit b91c3e4ea756 ("landlock: Add support for file reparenting with
LANDLOCK_ACCESS_FS_REFER").
To say it another way, this bug may lift the renaming and linking
limitations of the initial Landlock version, and a same ruleset can
enforce different restrictions depending on previous or next enforced
ruleset (i.e. inconsistent behavior). The LANDLOCK_ACCESS_FS_REFER right
cannot give access to data not already allowed, but this doesn't follow
the contract of the first Landlock ABI. This fix puts back the
limitation for sandboxes that didn't opt-in for this additional right.
For instance, if a first ruleset allows LANDLOCK_ACCESS_FS_MAKE_REG on
/dst and LANDLOCK_ACCESS_FS_REMOVE_FILE on /src, renaming /src/file to
/dst/file is denied. However, without this fix, stacking a new ruleset
which allows LANDLOCK_ACCESS_FS_REFER on / would now permit the
sandboxed thread to rename /src/file to /dst/file .
This change fixes the (absolute) rule access rights, which now always
forbid LANDLOCK_ACCESS_FS_REFER except when it is explicitly allowed
when creating a rule.
Making all domain handle LANDLOCK_ACCESS_FS_REFER was an initial
approach but there is two downsides:
* it makes the code more complex because we still want to check that a
rule allowing LANDLOCK_ACCESS_FS_REFER is legitimate according to the
ruleset's handled access rights (i.e. ABI v1 != ABI v2);
* it would not allow to identify if the user created a ruleset
explicitly handling LANDLOCK_ACCESS_FS_REFER or not, which will be an
issue to audit Landlock.
Instead, this change adds an ACCESS_INITIALLY_DENIED list of
denied-by-default rights, which (only) contains
LANDLOCK_ACCESS_FS_REFER. All domains are treated as if they are also
handling this list, but without modifying their fs_access_masks field.
A side effect is that the errno code returned by rename(2) or link(2)
*may* be changed from EXDEV to EACCES according to the enforced
restrictions. Indeed, we now have the mechanic to identify if an access
is denied because of a required right (e.g. LANDLOCK_ACCESS_FS_MAKE_REG,
LANDLOCK_ACCESS_FS_REMOVE_FILE) or if it is denied because of missing
LANDLOCK_ACCESS_FS_REFER rights. This may result in different errno
codes than for the initial Landlock version, but this approach is more
consistent and better for rename/link compatibility reasons, and it
wasn't possible before (hence no backport to ABI v1). The
layout1.rename_file test reflects this change.
Add 4 layout1.refer_denied_by_default* test suites to check that the
behavior of a ruleset not handling LANDLOCK_ACCESS_FS_REFER (ABI v1) is
unchanged even if another layer handles LANDLOCK_ACCESS_FS_REFER (i.e.
ABI v1 precedence). Make sure rule's absolute access rights are correct
by testing with and without a matching path. Add test_rename() and
test_exchange() helpers.
Extend layout1.inval tests to check that a denied-by-default access
right is not necessarily part of a domain's handled access rights.
Test coverage for security/landlock is 95.3% of 599 lines according to
gcc/gcov-11.
Fixes: b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER")
Reviewed-by: Paul Moore <paul@paul-moore.com>
Reviewed-by: Günther Noack <gnoack3000@gmail.com>
Link: https://lore.kernel.org/r/20220831203840.1370732-1-mic@digikod.net
Cc: stable@vger.kernel.org
[mic: Constify and slightly simplify test helpers]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2022-08-31 20:38:40 +00:00
|
|
|
size_t layer_level;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
|
landlock: Fix file reparenting without explicit LANDLOCK_ACCESS_FS_REFER
This change fixes a mis-handling of the LANDLOCK_ACCESS_FS_REFER right
when multiple rulesets/domains are stacked. The expected behaviour was
that an additional ruleset can only restrict the set of permitted
operations, but in this particular case, it was potentially possible to
re-gain the LANDLOCK_ACCESS_FS_REFER right.
With the introduction of LANDLOCK_ACCESS_FS_REFER, we added the first
globally denied-by-default access right. Indeed, this lifted an initial
Landlock limitation to rename and link files, which was initially always
denied when the source or the destination were different directories.
This led to an inconsistent backward compatibility behavior which was
only taken into account if no domain layer were using the new
LANDLOCK_ACCESS_FS_REFER right. However, when restricting a thread with
a new ruleset handling LANDLOCK_ACCESS_FS_REFER, all inherited parent
rulesets/layers not explicitly handling LANDLOCK_ACCESS_FS_REFER would
behave as if they were handling this access right and with all their
rules allowing it. This means that renaming and linking files could
became allowed by these parent layers, but all the other required
accesses must also be granted: all layers must allow file removal or
creation, and renaming and linking operations cannot lead to privilege
escalation according to the Landlock policy. See detailed explanation
in commit b91c3e4ea756 ("landlock: Add support for file reparenting with
LANDLOCK_ACCESS_FS_REFER").
To say it another way, this bug may lift the renaming and linking
limitations of the initial Landlock version, and a same ruleset can
enforce different restrictions depending on previous or next enforced
ruleset (i.e. inconsistent behavior). The LANDLOCK_ACCESS_FS_REFER right
cannot give access to data not already allowed, but this doesn't follow
the contract of the first Landlock ABI. This fix puts back the
limitation for sandboxes that didn't opt-in for this additional right.
For instance, if a first ruleset allows LANDLOCK_ACCESS_FS_MAKE_REG on
/dst and LANDLOCK_ACCESS_FS_REMOVE_FILE on /src, renaming /src/file to
/dst/file is denied. However, without this fix, stacking a new ruleset
which allows LANDLOCK_ACCESS_FS_REFER on / would now permit the
sandboxed thread to rename /src/file to /dst/file .
This change fixes the (absolute) rule access rights, which now always
forbid LANDLOCK_ACCESS_FS_REFER except when it is explicitly allowed
when creating a rule.
Making all domain handle LANDLOCK_ACCESS_FS_REFER was an initial
approach but there is two downsides:
* it makes the code more complex because we still want to check that a
rule allowing LANDLOCK_ACCESS_FS_REFER is legitimate according to the
ruleset's handled access rights (i.e. ABI v1 != ABI v2);
* it would not allow to identify if the user created a ruleset
explicitly handling LANDLOCK_ACCESS_FS_REFER or not, which will be an
issue to audit Landlock.
Instead, this change adds an ACCESS_INITIALLY_DENIED list of
denied-by-default rights, which (only) contains
LANDLOCK_ACCESS_FS_REFER. All domains are treated as if they are also
handling this list, but without modifying their fs_access_masks field.
A side effect is that the errno code returned by rename(2) or link(2)
*may* be changed from EXDEV to EACCES according to the enforced
restrictions. Indeed, we now have the mechanic to identify if an access
is denied because of a required right (e.g. LANDLOCK_ACCESS_FS_MAKE_REG,
LANDLOCK_ACCESS_FS_REMOVE_FILE) or if it is denied because of missing
LANDLOCK_ACCESS_FS_REFER rights. This may result in different errno
codes than for the initial Landlock version, but this approach is more
consistent and better for rename/link compatibility reasons, and it
wasn't possible before (hence no backport to ABI v1). The
layout1.rename_file test reflects this change.
Add 4 layout1.refer_denied_by_default* test suites to check that the
behavior of a ruleset not handling LANDLOCK_ACCESS_FS_REFER (ABI v1) is
unchanged even if another layer handles LANDLOCK_ACCESS_FS_REFER (i.e.
ABI v1 precedence). Make sure rule's absolute access rights are correct
by testing with and without a matching path. Add test_rename() and
test_exchange() helpers.
Extend layout1.inval tests to check that a denied-by-default access
right is not necessarily part of a domain's handled access rights.
Test coverage for security/landlock is 95.3% of 599 lines according to
gcc/gcov-11.
Fixes: b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER")
Reviewed-by: Paul Moore <paul@paul-moore.com>
Reviewed-by: Günther Noack <gnoack3000@gmail.com>
Link: https://lore.kernel.org/r/20220831203840.1370732-1-mic@digikod.net
Cc: stable@vger.kernel.org
[mic: Constify and slightly simplify test helpers]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2022-08-31 20:38:40 +00:00
|
|
|
for (layer_level = 0; layer_level < domain->num_layers; layer_level++)
|
2023-10-26 01:47:41 +00:00
|
|
|
access_dom |=
|
|
|
|
landlock_get_raw_fs_access_mask(domain, layer_level);
|
|
|
|
return access_dom;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
}
|
|
|
|
|
2023-10-26 01:47:41 +00:00
|
|
|
static access_mask_t
|
|
|
|
get_handled_fs_accesses(const struct landlock_ruleset *const domain)
|
|
|
|
{
|
|
|
|
/* Handles all initially denied by default access rights. */
|
|
|
|
return get_raw_handled_fs_accesses(domain) |
|
|
|
|
LANDLOCK_ACCESS_FS_INITIALLY_DENIED;
|
|
|
|
}
|
|
|
|
|
2024-03-07 09:52:03 +00:00
|
|
|
static const struct landlock_ruleset *
|
|
|
|
get_fs_domain(const struct landlock_ruleset *const domain)
|
2023-10-26 01:47:41 +00:00
|
|
|
{
|
2024-03-07 09:52:03 +00:00
|
|
|
if (!domain || !get_raw_handled_fs_accesses(domain))
|
2023-10-26 01:47:41 +00:00
|
|
|
return NULL;
|
|
|
|
|
2024-03-07 09:52:03 +00:00
|
|
|
return domain;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct landlock_ruleset *get_current_fs_domain(void)
|
|
|
|
{
|
|
|
|
return get_fs_domain(landlock_get_current_domain());
|
2023-10-26 01:47:41 +00:00
|
|
|
}
|
|
|
|
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/*
|
|
|
|
* Check that a destination file hierarchy has more restrictions than a source
|
|
|
|
* file hierarchy. This is only used for link and rename actions.
|
|
|
|
*
|
|
|
|
* @layer_masks_child2: Optional child masks.
|
|
|
|
*/
|
2023-12-08 15:51:13 +00:00
|
|
|
static bool no_more_access(
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
const layer_mask_t (*const layer_masks_parent1)[LANDLOCK_NUM_ACCESS_FS],
|
|
|
|
const layer_mask_t (*const layer_masks_child1)[LANDLOCK_NUM_ACCESS_FS],
|
|
|
|
const bool child1_is_directory,
|
|
|
|
const layer_mask_t (*const layer_masks_parent2)[LANDLOCK_NUM_ACCESS_FS],
|
|
|
|
const layer_mask_t (*const layer_masks_child2)[LANDLOCK_NUM_ACCESS_FS],
|
|
|
|
const bool child2_is_directory)
|
|
|
|
{
|
|
|
|
unsigned long access_bit;
|
|
|
|
|
|
|
|
for (access_bit = 0; access_bit < ARRAY_SIZE(*layer_masks_parent2);
|
|
|
|
access_bit++) {
|
|
|
|
/* Ignores accesses that only make sense for directories. */
|
|
|
|
const bool is_file_access =
|
|
|
|
!!(BIT_ULL(access_bit) & ACCESS_FILE);
|
|
|
|
|
|
|
|
if (child1_is_directory || is_file_access) {
|
|
|
|
/*
|
|
|
|
* Checks if the destination restrictions are a
|
|
|
|
* superset of the source ones (i.e. inherited access
|
|
|
|
* rights without child exceptions):
|
|
|
|
* restrictions(parent2) >= restrictions(child1)
|
|
|
|
*/
|
|
|
|
if ((((*layer_masks_parent1)[access_bit] &
|
|
|
|
(*layer_masks_child1)[access_bit]) |
|
|
|
|
(*layer_masks_parent2)[access_bit]) !=
|
|
|
|
(*layer_masks_parent2)[access_bit])
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!layer_masks_child2)
|
|
|
|
continue;
|
|
|
|
if (child2_is_directory || is_file_access) {
|
|
|
|
/*
|
|
|
|
* Checks inverted restrictions for RENAME_EXCHANGE:
|
|
|
|
* restrictions(parent1) >= restrictions(child2)
|
|
|
|
*/
|
|
|
|
if ((((*layer_masks_parent2)[access_bit] &
|
|
|
|
(*layer_masks_child2)[access_bit]) |
|
|
|
|
(*layer_masks_parent1)[access_bit]) !=
|
|
|
|
(*layer_masks_parent1)[access_bit])
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2024-01-18 11:36:32 +00:00
|
|
|
#define NMA_TRUE(...) KUNIT_EXPECT_TRUE(test, no_more_access(__VA_ARGS__))
|
|
|
|
#define NMA_FALSE(...) KUNIT_EXPECT_FALSE(test, no_more_access(__VA_ARGS__))
|
|
|
|
|
|
|
|
#ifdef CONFIG_SECURITY_LANDLOCK_KUNIT_TEST
|
|
|
|
|
|
|
|
static void test_no_more_access(struct kunit *const test)
|
|
|
|
{
|
|
|
|
const layer_mask_t rx0[LANDLOCK_NUM_ACCESS_FS] = {
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_EXECUTE)] = BIT_ULL(0),
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_READ_FILE)] = BIT_ULL(0),
|
|
|
|
};
|
|
|
|
const layer_mask_t mx0[LANDLOCK_NUM_ACCESS_FS] = {
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_EXECUTE)] = BIT_ULL(0),
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_MAKE_REG)] = BIT_ULL(0),
|
|
|
|
};
|
|
|
|
const layer_mask_t x0[LANDLOCK_NUM_ACCESS_FS] = {
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_EXECUTE)] = BIT_ULL(0),
|
|
|
|
};
|
|
|
|
const layer_mask_t x1[LANDLOCK_NUM_ACCESS_FS] = {
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_EXECUTE)] = BIT_ULL(1),
|
|
|
|
};
|
|
|
|
const layer_mask_t x01[LANDLOCK_NUM_ACCESS_FS] = {
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_EXECUTE)] = BIT_ULL(0) |
|
|
|
|
BIT_ULL(1),
|
|
|
|
};
|
|
|
|
const layer_mask_t allows_all[LANDLOCK_NUM_ACCESS_FS] = {};
|
|
|
|
|
|
|
|
/* Checks without restriction. */
|
|
|
|
NMA_TRUE(&x0, &allows_all, false, &allows_all, NULL, false);
|
|
|
|
NMA_TRUE(&allows_all, &x0, false, &allows_all, NULL, false);
|
|
|
|
NMA_FALSE(&x0, &x0, false, &allows_all, NULL, false);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Checks that we can only refer a file if no more access could be
|
|
|
|
* inherited.
|
|
|
|
*/
|
|
|
|
NMA_TRUE(&x0, &x0, false, &rx0, NULL, false);
|
|
|
|
NMA_TRUE(&rx0, &rx0, false, &rx0, NULL, false);
|
|
|
|
NMA_FALSE(&rx0, &rx0, false, &x0, NULL, false);
|
|
|
|
NMA_FALSE(&rx0, &rx0, false, &x1, NULL, false);
|
|
|
|
|
|
|
|
/* Checks allowed referring with different nested domains. */
|
|
|
|
NMA_TRUE(&x0, &x1, false, &x0, NULL, false);
|
|
|
|
NMA_TRUE(&x1, &x0, false, &x0, NULL, false);
|
|
|
|
NMA_TRUE(&x0, &x01, false, &x0, NULL, false);
|
|
|
|
NMA_TRUE(&x0, &x01, false, &rx0, NULL, false);
|
|
|
|
NMA_TRUE(&x01, &x0, false, &x0, NULL, false);
|
|
|
|
NMA_TRUE(&x01, &x0, false, &rx0, NULL, false);
|
|
|
|
NMA_FALSE(&x01, &x01, false, &x0, NULL, false);
|
|
|
|
|
|
|
|
/* Checks that file access rights are also enforced for a directory. */
|
|
|
|
NMA_FALSE(&rx0, &rx0, true, &x0, NULL, false);
|
|
|
|
|
|
|
|
/* Checks that directory access rights don't impact file referring... */
|
|
|
|
NMA_TRUE(&mx0, &mx0, false, &x0, NULL, false);
|
|
|
|
/* ...but only directory referring. */
|
|
|
|
NMA_FALSE(&mx0, &mx0, true, &x0, NULL, false);
|
|
|
|
|
|
|
|
/* Checks directory exchange. */
|
|
|
|
NMA_TRUE(&mx0, &mx0, true, &mx0, &mx0, true);
|
|
|
|
NMA_TRUE(&mx0, &mx0, true, &mx0, &x0, true);
|
|
|
|
NMA_FALSE(&mx0, &mx0, true, &x0, &mx0, true);
|
|
|
|
NMA_FALSE(&mx0, &mx0, true, &x0, &x0, true);
|
|
|
|
NMA_FALSE(&mx0, &mx0, true, &x1, &x1, true);
|
|
|
|
|
|
|
|
/* Checks file exchange with directory access rights... */
|
|
|
|
NMA_TRUE(&mx0, &mx0, false, &mx0, &mx0, false);
|
|
|
|
NMA_TRUE(&mx0, &mx0, false, &mx0, &x0, false);
|
|
|
|
NMA_TRUE(&mx0, &mx0, false, &x0, &mx0, false);
|
|
|
|
NMA_TRUE(&mx0, &mx0, false, &x0, &x0, false);
|
|
|
|
/* ...and with file access rights. */
|
|
|
|
NMA_TRUE(&rx0, &rx0, false, &rx0, &rx0, false);
|
|
|
|
NMA_TRUE(&rx0, &rx0, false, &rx0, &x0, false);
|
|
|
|
NMA_FALSE(&rx0, &rx0, false, &x0, &rx0, false);
|
|
|
|
NMA_FALSE(&rx0, &rx0, false, &x0, &x0, false);
|
|
|
|
NMA_FALSE(&rx0, &rx0, false, &x1, &x1, false);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allowing the following requests should not be a security risk
|
|
|
|
* because domain 0 denies execute access, and domain 1 is always
|
|
|
|
* nested with domain 0. However, adding an exception for this case
|
|
|
|
* would mean to check all nested domains to make sure none can get
|
|
|
|
* more privileges (e.g. processes only sandboxed by domain 0).
|
|
|
|
* Moreover, this behavior (i.e. composition of N domains) could then
|
|
|
|
* be inconsistent compared to domain 1's ruleset alone (e.g. it might
|
|
|
|
* be denied to link/rename with domain 1's ruleset, whereas it would
|
|
|
|
* be allowed if nested on top of domain 0). Another drawback would be
|
|
|
|
* to create a cover channel that could enable sandboxed processes to
|
|
|
|
* infer most of the filesystem restrictions from their domain. To
|
|
|
|
* make it simple, efficient, safe, and more consistent, this case is
|
|
|
|
* always denied.
|
|
|
|
*/
|
|
|
|
NMA_FALSE(&x1, &x1, false, &x0, NULL, false);
|
|
|
|
NMA_FALSE(&x1, &x1, false, &rx0, NULL, false);
|
|
|
|
NMA_FALSE(&x1, &x1, true, &x0, NULL, false);
|
|
|
|
NMA_FALSE(&x1, &x1, true, &rx0, NULL, false);
|
|
|
|
|
|
|
|
/* Checks the same case of exclusive domains with a file... */
|
|
|
|
NMA_TRUE(&x1, &x1, false, &x01, NULL, false);
|
|
|
|
NMA_FALSE(&x1, &x1, false, &x01, &x0, false);
|
|
|
|
NMA_FALSE(&x1, &x1, false, &x01, &x01, false);
|
|
|
|
NMA_FALSE(&x1, &x1, false, &x0, &x0, false);
|
|
|
|
/* ...and with a directory. */
|
|
|
|
NMA_FALSE(&x1, &x1, false, &x0, &x0, true);
|
|
|
|
NMA_FALSE(&x1, &x1, true, &x0, &x0, false);
|
|
|
|
NMA_FALSE(&x1, &x1, true, &x0, &x0, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_SECURITY_LANDLOCK_KUNIT_TEST */
|
|
|
|
|
|
|
|
#undef NMA_TRUE
|
|
|
|
#undef NMA_FALSE
|
|
|
|
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/*
|
|
|
|
* Removes @layer_masks accesses that are not requested.
|
|
|
|
*
|
|
|
|
* Returns true if the request is allowed, false otherwise.
|
|
|
|
*/
|
2023-12-08 15:51:13 +00:00
|
|
|
static bool
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
scope_to_request(const access_mask_t access_request,
|
|
|
|
layer_mask_t (*const layer_masks)[LANDLOCK_NUM_ACCESS_FS])
|
|
|
|
{
|
|
|
|
const unsigned long access_req = access_request;
|
|
|
|
unsigned long access_bit;
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(!layer_masks))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
for_each_clear_bit(access_bit, &access_req, ARRAY_SIZE(*layer_masks))
|
|
|
|
(*layer_masks)[access_bit] = 0;
|
|
|
|
return !memchr_inv(layer_masks, 0, sizeof(*layer_masks));
|
|
|
|
}
|
|
|
|
|
2024-01-18 11:36:32 +00:00
|
|
|
#ifdef CONFIG_SECURITY_LANDLOCK_KUNIT_TEST
|
|
|
|
|
|
|
|
static void test_scope_to_request_with_exec_none(struct kunit *const test)
|
|
|
|
{
|
|
|
|
/* Allows everything. */
|
|
|
|
layer_mask_t layer_masks[LANDLOCK_NUM_ACCESS_FS] = {};
|
|
|
|
|
|
|
|
/* Checks and scopes with execute. */
|
|
|
|
KUNIT_EXPECT_TRUE(test, scope_to_request(LANDLOCK_ACCESS_FS_EXECUTE,
|
|
|
|
&layer_masks));
|
|
|
|
KUNIT_EXPECT_EQ(test, 0,
|
|
|
|
layer_masks[BIT_INDEX(LANDLOCK_ACCESS_FS_EXECUTE)]);
|
|
|
|
KUNIT_EXPECT_EQ(test, 0,
|
|
|
|
layer_masks[BIT_INDEX(LANDLOCK_ACCESS_FS_WRITE_FILE)]);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void test_scope_to_request_with_exec_some(struct kunit *const test)
|
|
|
|
{
|
|
|
|
/* Denies execute and write. */
|
|
|
|
layer_mask_t layer_masks[LANDLOCK_NUM_ACCESS_FS] = {
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_EXECUTE)] = BIT_ULL(0),
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_WRITE_FILE)] = BIT_ULL(1),
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Checks and scopes with execute. */
|
|
|
|
KUNIT_EXPECT_FALSE(test, scope_to_request(LANDLOCK_ACCESS_FS_EXECUTE,
|
|
|
|
&layer_masks));
|
|
|
|
KUNIT_EXPECT_EQ(test, BIT_ULL(0),
|
|
|
|
layer_masks[BIT_INDEX(LANDLOCK_ACCESS_FS_EXECUTE)]);
|
|
|
|
KUNIT_EXPECT_EQ(test, 0,
|
|
|
|
layer_masks[BIT_INDEX(LANDLOCK_ACCESS_FS_WRITE_FILE)]);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void test_scope_to_request_without_access(struct kunit *const test)
|
|
|
|
{
|
|
|
|
/* Denies execute and write. */
|
|
|
|
layer_mask_t layer_masks[LANDLOCK_NUM_ACCESS_FS] = {
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_EXECUTE)] = BIT_ULL(0),
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_WRITE_FILE)] = BIT_ULL(1),
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Checks and scopes without access request. */
|
|
|
|
KUNIT_EXPECT_TRUE(test, scope_to_request(0, &layer_masks));
|
|
|
|
KUNIT_EXPECT_EQ(test, 0,
|
|
|
|
layer_masks[BIT_INDEX(LANDLOCK_ACCESS_FS_EXECUTE)]);
|
|
|
|
KUNIT_EXPECT_EQ(test, 0,
|
|
|
|
layer_masks[BIT_INDEX(LANDLOCK_ACCESS_FS_WRITE_FILE)]);
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_SECURITY_LANDLOCK_KUNIT_TEST */
|
|
|
|
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/*
|
|
|
|
* Returns true if there is at least one access right different than
|
|
|
|
* LANDLOCK_ACCESS_FS_REFER.
|
|
|
|
*/
|
2023-12-08 15:51:13 +00:00
|
|
|
static bool
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
is_eacces(const layer_mask_t (*const layer_masks)[LANDLOCK_NUM_ACCESS_FS],
|
|
|
|
const access_mask_t access_request)
|
|
|
|
{
|
|
|
|
unsigned long access_bit;
|
|
|
|
/* LANDLOCK_ACCESS_FS_REFER alone must return -EXDEV. */
|
|
|
|
const unsigned long access_check = access_request &
|
|
|
|
~LANDLOCK_ACCESS_FS_REFER;
|
|
|
|
|
|
|
|
if (!layer_masks)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
for_each_set_bit(access_bit, &access_check, ARRAY_SIZE(*layer_masks)) {
|
|
|
|
if ((*layer_masks)[access_bit])
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2024-01-18 11:36:32 +00:00
|
|
|
#define IE_TRUE(...) KUNIT_EXPECT_TRUE(test, is_eacces(__VA_ARGS__))
|
|
|
|
#define IE_FALSE(...) KUNIT_EXPECT_FALSE(test, is_eacces(__VA_ARGS__))
|
|
|
|
|
|
|
|
#ifdef CONFIG_SECURITY_LANDLOCK_KUNIT_TEST
|
|
|
|
|
|
|
|
static void test_is_eacces_with_none(struct kunit *const test)
|
|
|
|
{
|
|
|
|
const layer_mask_t layer_masks[LANDLOCK_NUM_ACCESS_FS] = {};
|
|
|
|
|
|
|
|
IE_FALSE(&layer_masks, 0);
|
|
|
|
IE_FALSE(&layer_masks, LANDLOCK_ACCESS_FS_REFER);
|
|
|
|
IE_FALSE(&layer_masks, LANDLOCK_ACCESS_FS_EXECUTE);
|
|
|
|
IE_FALSE(&layer_masks, LANDLOCK_ACCESS_FS_WRITE_FILE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void test_is_eacces_with_refer(struct kunit *const test)
|
|
|
|
{
|
|
|
|
const layer_mask_t layer_masks[LANDLOCK_NUM_ACCESS_FS] = {
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_REFER)] = BIT_ULL(0),
|
|
|
|
};
|
|
|
|
|
|
|
|
IE_FALSE(&layer_masks, 0);
|
|
|
|
IE_FALSE(&layer_masks, LANDLOCK_ACCESS_FS_REFER);
|
|
|
|
IE_FALSE(&layer_masks, LANDLOCK_ACCESS_FS_EXECUTE);
|
|
|
|
IE_FALSE(&layer_masks, LANDLOCK_ACCESS_FS_WRITE_FILE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void test_is_eacces_with_write(struct kunit *const test)
|
|
|
|
{
|
|
|
|
const layer_mask_t layer_masks[LANDLOCK_NUM_ACCESS_FS] = {
|
|
|
|
[BIT_INDEX(LANDLOCK_ACCESS_FS_WRITE_FILE)] = BIT_ULL(0),
|
|
|
|
};
|
|
|
|
|
|
|
|
IE_FALSE(&layer_masks, 0);
|
|
|
|
IE_FALSE(&layer_masks, LANDLOCK_ACCESS_FS_REFER);
|
|
|
|
IE_FALSE(&layer_masks, LANDLOCK_ACCESS_FS_EXECUTE);
|
|
|
|
|
|
|
|
IE_TRUE(&layer_masks, LANDLOCK_ACCESS_FS_WRITE_FILE);
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_SECURITY_LANDLOCK_KUNIT_TEST */
|
|
|
|
|
|
|
|
#undef IE_TRUE
|
|
|
|
#undef IE_FALSE
|
|
|
|
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/**
|
2022-10-18 18:22:07 +00:00
|
|
|
* is_access_to_paths_allowed - Check accesses for requests with a common path
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
*
|
|
|
|
* @domain: Domain to check against.
|
|
|
|
* @path: File hierarchy to walk through.
|
|
|
|
* @access_request_parent1: Accesses to check, once @layer_masks_parent1 is
|
|
|
|
* equal to @layer_masks_parent2 (if any). This is tied to the unique
|
|
|
|
* requested path for most actions, or the source in case of a refer action
|
|
|
|
* (i.e. rename or link), or the source and destination in case of
|
|
|
|
* RENAME_EXCHANGE.
|
|
|
|
* @layer_masks_parent1: Pointer to a matrix of layer masks per access
|
|
|
|
* masks, identifying the layers that forbid a specific access. Bits from
|
|
|
|
* this matrix can be unset according to the @path walk. An empty matrix
|
|
|
|
* means that @domain allows all possible Landlock accesses (i.e. not only
|
|
|
|
* those identified by @access_request_parent1). This matrix can
|
|
|
|
* initially refer to domain layer masks and, when the accesses for the
|
|
|
|
* destination and source are the same, to requested layer masks.
|
|
|
|
* @dentry_child1: Dentry to the initial child of the parent1 path. This
|
|
|
|
* pointer must be NULL for non-refer actions (i.e. not link nor rename).
|
|
|
|
* @access_request_parent2: Similar to @access_request_parent1 but for a
|
|
|
|
* request involving a source and a destination. This refers to the
|
|
|
|
* destination, except in case of RENAME_EXCHANGE where it also refers to
|
|
|
|
* the source. Must be set to 0 when using a simple path request.
|
|
|
|
* @layer_masks_parent2: Similar to @layer_masks_parent1 but for a refer
|
|
|
|
* action. This must be NULL otherwise.
|
|
|
|
* @dentry_child2: Dentry to the initial child of the parent2 path. This
|
|
|
|
* pointer is only set for RENAME_EXCHANGE actions and must be NULL
|
|
|
|
* otherwise.
|
|
|
|
*
|
|
|
|
* This helper first checks that the destination has a superset of restrictions
|
|
|
|
* compared to the source (if any) for a common path. Because of
|
|
|
|
* RENAME_EXCHANGE actions, source and destinations may be swapped. It then
|
|
|
|
* checks that the collected accesses and the remaining ones are enough to
|
|
|
|
* allow the request.
|
|
|
|
*
|
|
|
|
* Returns:
|
2022-10-18 18:22:07 +00:00
|
|
|
* - true if the access request is granted;
|
|
|
|
* - false otherwise.
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
*/
|
2022-10-18 18:22:07 +00:00
|
|
|
static bool is_access_to_paths_allowed(
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
const struct landlock_ruleset *const domain,
|
|
|
|
const struct path *const path,
|
|
|
|
const access_mask_t access_request_parent1,
|
|
|
|
layer_mask_t (*const layer_masks_parent1)[LANDLOCK_NUM_ACCESS_FS],
|
|
|
|
const struct dentry *const dentry_child1,
|
|
|
|
const access_mask_t access_request_parent2,
|
|
|
|
layer_mask_t (*const layer_masks_parent2)[LANDLOCK_NUM_ACCESS_FS],
|
|
|
|
const struct dentry *const dentry_child2)
|
|
|
|
{
|
|
|
|
bool allowed_parent1 = false, allowed_parent2 = false, is_dom_check,
|
|
|
|
child1_is_directory = true, child2_is_directory = true;
|
|
|
|
struct path walker_path;
|
|
|
|
access_mask_t access_masked_parent1, access_masked_parent2;
|
|
|
|
layer_mask_t _layer_masks_child1[LANDLOCK_NUM_ACCESS_FS],
|
|
|
|
_layer_masks_child2[LANDLOCK_NUM_ACCESS_FS];
|
|
|
|
layer_mask_t(*layer_masks_child1)[LANDLOCK_NUM_ACCESS_FS] = NULL,
|
|
|
|
(*layer_masks_child2)[LANDLOCK_NUM_ACCESS_FS] = NULL;
|
|
|
|
|
|
|
|
if (!access_request_parent1 && !access_request_parent2)
|
2022-10-18 18:22:07 +00:00
|
|
|
return true;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
if (WARN_ON_ONCE(!domain || !path))
|
2022-10-18 18:22:07 +00:00
|
|
|
return true;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
if (is_nouser_or_private(path->dentry))
|
2022-10-18 18:22:07 +00:00
|
|
|
return true;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
if (WARN_ON_ONCE(domain->num_layers < 1 || !layer_masks_parent1))
|
2022-10-18 18:22:07 +00:00
|
|
|
return false;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
|
|
|
|
if (unlikely(layer_masks_parent2)) {
|
|
|
|
if (WARN_ON_ONCE(!dentry_child1))
|
2022-10-18 18:22:07 +00:00
|
|
|
return false;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/*
|
|
|
|
* For a double request, first check for potential privilege
|
|
|
|
* escalation by looking at domain handled accesses (which are
|
|
|
|
* a superset of the meaningful requested accesses).
|
|
|
|
*/
|
|
|
|
access_masked_parent1 = access_masked_parent2 =
|
2023-10-26 01:47:41 +00:00
|
|
|
get_handled_fs_accesses(domain);
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
is_dom_check = true;
|
|
|
|
} else {
|
|
|
|
if (WARN_ON_ONCE(dentry_child1 || dentry_child2))
|
2022-10-18 18:22:07 +00:00
|
|
|
return false;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/* For a simple request, only check for requested accesses. */
|
|
|
|
access_masked_parent1 = access_request_parent1;
|
|
|
|
access_masked_parent2 = access_request_parent2;
|
|
|
|
is_dom_check = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (unlikely(dentry_child1)) {
|
2023-10-26 01:47:45 +00:00
|
|
|
landlock_unmask_layers(
|
|
|
|
find_rule(domain, dentry_child1),
|
|
|
|
landlock_init_layer_masks(
|
|
|
|
domain, LANDLOCK_MASK_ACCESS_FS,
|
|
|
|
&_layer_masks_child1, LANDLOCK_KEY_INODE),
|
|
|
|
&_layer_masks_child1, ARRAY_SIZE(_layer_masks_child1));
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
layer_masks_child1 = &_layer_masks_child1;
|
|
|
|
child1_is_directory = d_is_dir(dentry_child1);
|
|
|
|
}
|
|
|
|
if (unlikely(dentry_child2)) {
|
2023-10-26 01:47:45 +00:00
|
|
|
landlock_unmask_layers(
|
|
|
|
find_rule(domain, dentry_child2),
|
|
|
|
landlock_init_layer_masks(
|
|
|
|
domain, LANDLOCK_MASK_ACCESS_FS,
|
|
|
|
&_layer_masks_child2, LANDLOCK_KEY_INODE),
|
|
|
|
&_layer_masks_child2, ARRAY_SIZE(_layer_masks_child2));
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
layer_masks_child2 = &_layer_masks_child2;
|
|
|
|
child2_is_directory = d_is_dir(dentry_child2);
|
|
|
|
}
|
2021-04-22 15:41:17 +00:00
|
|
|
|
|
|
|
walker_path = *path;
|
|
|
|
path_get(&walker_path);
|
|
|
|
/*
|
|
|
|
* We need to walk through all the hierarchy to not miss any relevant
|
|
|
|
* restriction.
|
|
|
|
*/
|
|
|
|
while (true) {
|
|
|
|
struct dentry *parent_dentry;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
const struct landlock_rule *rule;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If at least all accesses allowed on the destination are
|
|
|
|
* already allowed on the source, respectively if there is at
|
|
|
|
* least as much as restrictions on the destination than on the
|
|
|
|
* source, then we can safely refer files from the source to
|
|
|
|
* the destination without risking a privilege escalation.
|
|
|
|
* This also applies in the case of RENAME_EXCHANGE, which
|
|
|
|
* implies checks on both direction. This is crucial for
|
|
|
|
* standalone multilayered security policies. Furthermore,
|
|
|
|
* this helps avoid policy writers to shoot themselves in the
|
|
|
|
* foot.
|
|
|
|
*/
|
|
|
|
if (unlikely(is_dom_check &&
|
|
|
|
no_more_access(
|
|
|
|
layer_masks_parent1, layer_masks_child1,
|
|
|
|
child1_is_directory, layer_masks_parent2,
|
|
|
|
layer_masks_child2,
|
|
|
|
child2_is_directory))) {
|
|
|
|
allowed_parent1 = scope_to_request(
|
|
|
|
access_request_parent1, layer_masks_parent1);
|
|
|
|
allowed_parent2 = scope_to_request(
|
|
|
|
access_request_parent2, layer_masks_parent2);
|
|
|
|
|
|
|
|
/* Stops when all accesses are granted. */
|
|
|
|
if (allowed_parent1 && allowed_parent2)
|
|
|
|
break;
|
2021-04-22 15:41:17 +00:00
|
|
|
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/*
|
|
|
|
* Now, downgrades the remaining checks from domain
|
|
|
|
* handled accesses to requested accesses.
|
|
|
|
*/
|
|
|
|
is_dom_check = false;
|
|
|
|
access_masked_parent1 = access_request_parent1;
|
|
|
|
access_masked_parent2 = access_request_parent2;
|
|
|
|
}
|
|
|
|
|
|
|
|
rule = find_rule(domain, walker_path.dentry);
|
2023-10-26 01:47:44 +00:00
|
|
|
allowed_parent1 = landlock_unmask_layers(
|
2023-10-26 01:47:45 +00:00
|
|
|
rule, access_masked_parent1, layer_masks_parent1,
|
|
|
|
ARRAY_SIZE(*layer_masks_parent1));
|
2023-10-26 01:47:44 +00:00
|
|
|
allowed_parent2 = landlock_unmask_layers(
|
2023-10-26 01:47:45 +00:00
|
|
|
rule, access_masked_parent2, layer_masks_parent2,
|
|
|
|
ARRAY_SIZE(*layer_masks_parent2));
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
|
|
|
|
/* Stops when a rule from each layer grants access. */
|
|
|
|
if (allowed_parent1 && allowed_parent2)
|
2021-04-22 15:41:17 +00:00
|
|
|
break;
|
|
|
|
jump_up:
|
|
|
|
if (walker_path.dentry == walker_path.mnt->mnt_root) {
|
|
|
|
if (follow_up(&walker_path)) {
|
|
|
|
/* Ignores hidden mount points. */
|
|
|
|
goto jump_up;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Stops at the real root. Denies access
|
|
|
|
* because not all layers have granted access.
|
|
|
|
*/
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (unlikely(IS_ROOT(walker_path.dentry))) {
|
|
|
|
/*
|
|
|
|
* Stops at disconnected root directories. Only allows
|
|
|
|
* access to internal filesystems (e.g. nsfs, which is
|
|
|
|
* reachable through /proc/<pid>/ns/<namespace>).
|
|
|
|
*/
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
allowed_parent1 = allowed_parent2 =
|
|
|
|
!!(walker_path.mnt->mnt_flags & MNT_INTERNAL);
|
2021-04-22 15:41:17 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
parent_dentry = dget_parent(walker_path.dentry);
|
|
|
|
dput(walker_path.dentry);
|
|
|
|
walker_path.dentry = parent_dentry;
|
|
|
|
}
|
|
|
|
path_put(&walker_path);
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
|
2022-10-18 18:22:07 +00:00
|
|
|
return allowed_parent1 && allowed_parent2;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
}
|
|
|
|
|
2023-12-08 15:51:13 +00:00
|
|
|
static int check_access_path(const struct landlock_ruleset *const domain,
|
|
|
|
const struct path *const path,
|
|
|
|
access_mask_t access_request)
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
{
|
|
|
|
layer_mask_t layer_masks[LANDLOCK_NUM_ACCESS_FS] = {};
|
|
|
|
|
2023-10-26 01:47:45 +00:00
|
|
|
access_request = landlock_init_layer_masks(
|
|
|
|
domain, access_request, &layer_masks, LANDLOCK_KEY_INODE);
|
2022-10-18 18:22:07 +00:00
|
|
|
if (is_access_to_paths_allowed(domain, path, access_request,
|
|
|
|
&layer_masks, NULL, 0, NULL, NULL))
|
|
|
|
return 0;
|
|
|
|
return -EACCES;
|
2021-04-22 15:41:17 +00:00
|
|
|
}
|
|
|
|
|
2023-12-08 15:51:13 +00:00
|
|
|
static int current_check_access_path(const struct path *const path,
|
|
|
|
const access_mask_t access_request)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
2023-10-26 01:47:41 +00:00
|
|
|
const struct landlock_ruleset *const dom = get_current_fs_domain();
|
2021-04-22 15:41:17 +00:00
|
|
|
|
|
|
|
if (!dom)
|
|
|
|
return 0;
|
|
|
|
return check_access_path(dom, path, access_request);
|
|
|
|
}
|
|
|
|
|
2023-12-08 15:51:13 +00:00
|
|
|
static access_mask_t get_mode_access(const umode_t mode)
|
2022-05-06 16:10:55 +00:00
|
|
|
{
|
|
|
|
switch (mode & S_IFMT) {
|
|
|
|
case S_IFLNK:
|
|
|
|
return LANDLOCK_ACCESS_FS_MAKE_SYM;
|
|
|
|
case 0:
|
|
|
|
/* A zero mode translates to S_IFREG. */
|
|
|
|
case S_IFREG:
|
|
|
|
return LANDLOCK_ACCESS_FS_MAKE_REG;
|
|
|
|
case S_IFDIR:
|
|
|
|
return LANDLOCK_ACCESS_FS_MAKE_DIR;
|
|
|
|
case S_IFCHR:
|
|
|
|
return LANDLOCK_ACCESS_FS_MAKE_CHAR;
|
|
|
|
case S_IFBLK:
|
|
|
|
return LANDLOCK_ACCESS_FS_MAKE_BLOCK;
|
|
|
|
case S_IFIFO:
|
|
|
|
return LANDLOCK_ACCESS_FS_MAKE_FIFO;
|
|
|
|
case S_IFSOCK:
|
|
|
|
return LANDLOCK_ACCESS_FS_MAKE_SOCK;
|
|
|
|
default:
|
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-12-08 15:51:13 +00:00
|
|
|
static access_mask_t maybe_remove(const struct dentry *const dentry)
|
2022-05-06 16:10:55 +00:00
|
|
|
{
|
|
|
|
if (d_is_negative(dentry))
|
|
|
|
return 0;
|
|
|
|
return d_is_dir(dentry) ? LANDLOCK_ACCESS_FS_REMOVE_DIR :
|
|
|
|
LANDLOCK_ACCESS_FS_REMOVE_FILE;
|
|
|
|
}
|
|
|
|
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/**
|
|
|
|
* collect_domain_accesses - Walk through a file path and collect accesses
|
|
|
|
*
|
|
|
|
* @domain: Domain to check against.
|
|
|
|
* @mnt_root: Last directory to check.
|
|
|
|
* @dir: Directory to start the walk from.
|
|
|
|
* @layer_masks_dom: Where to store the collected accesses.
|
|
|
|
*
|
|
|
|
* This helper is useful to begin a path walk from the @dir directory to a
|
|
|
|
* @mnt_root directory used as a mount point. This mount point is the common
|
|
|
|
* ancestor between the source and the destination of a renamed and linked
|
|
|
|
* file. While walking from @dir to @mnt_root, we record all the domain's
|
|
|
|
* allowed accesses in @layer_masks_dom.
|
|
|
|
*
|
2022-10-18 18:22:07 +00:00
|
|
|
* This is similar to is_access_to_paths_allowed() but much simpler because it
|
|
|
|
* only handles walking on the same mount point and only checks one set of
|
|
|
|
* accesses.
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* - true if all the domain access rights are allowed for @dir;
|
|
|
|
* - false if the walk reached @mnt_root.
|
|
|
|
*/
|
|
|
|
static bool collect_domain_accesses(
|
|
|
|
const struct landlock_ruleset *const domain,
|
|
|
|
const struct dentry *const mnt_root, struct dentry *dir,
|
|
|
|
layer_mask_t (*const layer_masks_dom)[LANDLOCK_NUM_ACCESS_FS])
|
|
|
|
{
|
|
|
|
unsigned long access_dom;
|
|
|
|
bool ret = false;
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(!domain || !mnt_root || !dir || !layer_masks_dom))
|
|
|
|
return true;
|
|
|
|
if (is_nouser_or_private(dir))
|
|
|
|
return true;
|
|
|
|
|
2023-10-26 01:47:44 +00:00
|
|
|
access_dom = landlock_init_layer_masks(domain, LANDLOCK_MASK_ACCESS_FS,
|
2023-10-26 01:47:45 +00:00
|
|
|
layer_masks_dom,
|
|
|
|
LANDLOCK_KEY_INODE);
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
|
|
|
|
dget(dir);
|
|
|
|
while (true) {
|
|
|
|
struct dentry *parent_dentry;
|
|
|
|
|
|
|
|
/* Gets all layers allowing all domain accesses. */
|
2023-10-26 01:47:44 +00:00
|
|
|
if (landlock_unmask_layers(find_rule(domain, dir), access_dom,
|
2023-10-26 01:47:45 +00:00
|
|
|
layer_masks_dom,
|
|
|
|
ARRAY_SIZE(*layer_masks_dom))) {
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/*
|
|
|
|
* Stops when all handled accesses are allowed by at
|
|
|
|
* least one rule in each layer.
|
|
|
|
*/
|
|
|
|
ret = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We should not reach a root other than @mnt_root. */
|
|
|
|
if (dir == mnt_root || WARN_ON_ONCE(IS_ROOT(dir)))
|
|
|
|
break;
|
|
|
|
|
|
|
|
parent_dentry = dget_parent(dir);
|
|
|
|
dput(dir);
|
|
|
|
dir = parent_dentry;
|
|
|
|
}
|
|
|
|
dput(dir);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* current_check_refer_path - Check if a rename or link action is allowed
|
|
|
|
*
|
|
|
|
* @old_dentry: File or directory requested to be moved or linked.
|
|
|
|
* @new_dir: Destination parent directory.
|
|
|
|
* @new_dentry: Destination file or directory.
|
|
|
|
* @removable: Sets to true if it is a rename operation.
|
|
|
|
* @exchange: Sets to true if it is a rename operation with RENAME_EXCHANGE.
|
|
|
|
*
|
|
|
|
* Because of its unprivileged constraints, Landlock relies on file hierarchies
|
|
|
|
* (and not only inodes) to tie access rights to files. Being able to link or
|
|
|
|
* rename a file hierarchy brings some challenges. Indeed, moving or linking a
|
|
|
|
* file (i.e. creating a new reference to an inode) can have an impact on the
|
|
|
|
* actions allowed for a set of files if it would change its parent directory
|
|
|
|
* (i.e. reparenting).
|
|
|
|
*
|
|
|
|
* To avoid trivial access right bypasses, Landlock first checks if the file or
|
|
|
|
* directory requested to be moved would gain new access rights inherited from
|
|
|
|
* its new hierarchy. Before returning any error, Landlock then checks that
|
|
|
|
* the parent source hierarchy and the destination hierarchy would allow the
|
|
|
|
* link or rename action. If it is not the case, an error with EACCES is
|
|
|
|
* returned to inform user space that there is no way to remove or create the
|
|
|
|
* requested source file type. If it should be allowed but the new inherited
|
|
|
|
* access rights would be greater than the source access rights, then the
|
|
|
|
* kernel returns an error with EXDEV. Prioritizing EACCES over EXDEV enables
|
|
|
|
* user space to abort the whole operation if there is no way to do it, or to
|
|
|
|
* manually copy the source to the destination if this remains allowed, e.g.
|
|
|
|
* because file creation is allowed on the destination directory but not direct
|
|
|
|
* linking.
|
|
|
|
*
|
|
|
|
* To achieve this goal, the kernel needs to compare two file hierarchies: the
|
|
|
|
* one identifying the source file or directory (including itself), and the
|
|
|
|
* destination one. This can be seen as a multilayer partial ordering problem.
|
|
|
|
* The kernel walks through these paths and collects in a matrix the access
|
|
|
|
* rights that are denied per layer. These matrices are then compared to see
|
|
|
|
* if the destination one has more (or the same) restrictions as the source
|
|
|
|
* one. If this is the case, the requested action will not return EXDEV, which
|
|
|
|
* doesn't mean the action is allowed. The parent hierarchy of the source
|
|
|
|
* (i.e. parent directory), and the destination hierarchy must also be checked
|
|
|
|
* to verify that they explicitly allow such action (i.e. referencing,
|
|
|
|
* creation and potentially removal rights). The kernel implementation is then
|
|
|
|
* required to rely on potentially four matrices of access rights: one for the
|
|
|
|
* source file or directory (i.e. the child), a potentially other one for the
|
|
|
|
* other source/destination (in case of RENAME_EXCHANGE), one for the source
|
|
|
|
* parent hierarchy and a last one for the destination hierarchy. These
|
|
|
|
* ephemeral matrices take some space on the stack, which limits the number of
|
|
|
|
* layers to a deemed reasonable number: 16.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* - 0 if access is allowed;
|
|
|
|
* - -EXDEV if @old_dentry would inherit new access rights from @new_dir;
|
|
|
|
* - -EACCES if file removal or creation is denied.
|
|
|
|
*/
|
|
|
|
static int current_check_refer_path(struct dentry *const old_dentry,
|
|
|
|
const struct path *const new_dir,
|
|
|
|
struct dentry *const new_dentry,
|
|
|
|
const bool removable, const bool exchange)
|
|
|
|
{
|
2023-10-26 01:47:41 +00:00
|
|
|
const struct landlock_ruleset *const dom = get_current_fs_domain();
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
bool allow_parent1, allow_parent2;
|
|
|
|
access_mask_t access_request_parent1, access_request_parent2;
|
|
|
|
struct path mnt_dir;
|
2024-05-16 18:19:34 +00:00
|
|
|
struct dentry *old_parent;
|
landlock: Fix asymmetric private inodes referring
When linking or renaming a file, if only one of the source or
destination directory is backed by an S_PRIVATE inode, then the related
set of layer masks would be used as uninitialized by
is_access_to_paths_allowed(). This would result to indeterministic
access for one side instead of always being allowed.
This bug could only be triggered with a mounted filesystem containing
both S_PRIVATE and !S_PRIVATE inodes, which doesn't seem possible.
The collect_domain_accesses() calls return early if
is_nouser_or_private() returns false, which means that the directory's
superblock has SB_NOUSER or its inode has S_PRIVATE. Because rename or
link actions are only allowed on the same mounted filesystem, the
superblock is always the same for both source and destination
directories. However, it might be possible in theory to have an
S_PRIVATE parent source inode with an !S_PRIVATE parent destination
inode, or vice versa.
To make sure this case is not an issue, explicitly initialized both set
of layer masks to 0, which means to allow all actions on the related
side. If at least on side has !S_PRIVATE, then
collect_domain_accesses() and is_access_to_paths_allowed() check for the
required access rights.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Günther Noack <gnoack@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Shervin Oloumi <enlightened@chromium.org>
Cc: stable@vger.kernel.org
Fixes: b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER")
Link: https://lore.kernel.org/r/20240219190345.2928627-1-mic@digikod.net
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-02-19 19:03:45 +00:00
|
|
|
layer_mask_t layer_masks_parent1[LANDLOCK_NUM_ACCESS_FS] = {},
|
|
|
|
layer_masks_parent2[LANDLOCK_NUM_ACCESS_FS] = {};
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
|
|
|
|
if (!dom)
|
|
|
|
return 0;
|
|
|
|
if (WARN_ON_ONCE(dom->num_layers < 1))
|
|
|
|
return -EACCES;
|
|
|
|
if (unlikely(d_is_negative(old_dentry)))
|
|
|
|
return -ENOENT;
|
|
|
|
if (exchange) {
|
|
|
|
if (unlikely(d_is_negative(new_dentry)))
|
|
|
|
return -ENOENT;
|
|
|
|
access_request_parent1 =
|
|
|
|
get_mode_access(d_backing_inode(new_dentry)->i_mode);
|
|
|
|
} else {
|
|
|
|
access_request_parent1 = 0;
|
|
|
|
}
|
|
|
|
access_request_parent2 =
|
|
|
|
get_mode_access(d_backing_inode(old_dentry)->i_mode);
|
|
|
|
if (removable) {
|
|
|
|
access_request_parent1 |= maybe_remove(old_dentry);
|
|
|
|
access_request_parent2 |= maybe_remove(new_dentry);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The mount points are the same for old and new paths, cf. EXDEV. */
|
|
|
|
if (old_dentry->d_parent == new_dir->dentry) {
|
|
|
|
/*
|
|
|
|
* The LANDLOCK_ACCESS_FS_REFER access right is not required
|
|
|
|
* for same-directory referer (i.e. no reparenting).
|
|
|
|
*/
|
2023-10-26 01:47:44 +00:00
|
|
|
access_request_parent1 = landlock_init_layer_masks(
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
dom, access_request_parent1 | access_request_parent2,
|
2023-10-26 01:47:45 +00:00
|
|
|
&layer_masks_parent1, LANDLOCK_KEY_INODE);
|
2022-10-18 18:22:07 +00:00
|
|
|
if (is_access_to_paths_allowed(
|
|
|
|
dom, new_dir, access_request_parent1,
|
|
|
|
&layer_masks_parent1, NULL, 0, NULL, NULL))
|
|
|
|
return 0;
|
|
|
|
return -EACCES;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
access_request_parent1 |= LANDLOCK_ACCESS_FS_REFER;
|
|
|
|
access_request_parent2 |= LANDLOCK_ACCESS_FS_REFER;
|
|
|
|
|
|
|
|
/* Saves the common mount point. */
|
|
|
|
mnt_dir.mnt = new_dir->mnt;
|
|
|
|
mnt_dir.dentry = new_dir->mnt->mnt_root;
|
|
|
|
|
2024-05-16 18:19:34 +00:00
|
|
|
/*
|
|
|
|
* old_dentry may be the root of the common mount point and
|
|
|
|
* !IS_ROOT(old_dentry) at the same time (e.g. with open_tree() and
|
|
|
|
* OPEN_TREE_CLONE). We do not need to call dget(old_parent) because
|
|
|
|
* we keep a reference to old_dentry.
|
|
|
|
*/
|
|
|
|
old_parent = (old_dentry == mnt_dir.dentry) ? old_dentry :
|
|
|
|
old_dentry->d_parent;
|
|
|
|
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/* new_dir->dentry is equal to new_dentry->d_parent */
|
2024-05-16 18:19:34 +00:00
|
|
|
allow_parent1 = collect_domain_accesses(dom, mnt_dir.dentry, old_parent,
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
&layer_masks_parent1);
|
|
|
|
allow_parent2 = collect_domain_accesses(
|
|
|
|
dom, mnt_dir.dentry, new_dir->dentry, &layer_masks_parent2);
|
|
|
|
|
|
|
|
if (allow_parent1 && allow_parent2)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* To be able to compare source and destination domain access rights,
|
|
|
|
* take into account the @old_dentry access rights aggregated with its
|
|
|
|
* parent access rights. This will be useful to compare with the
|
|
|
|
* destination parent access rights.
|
|
|
|
*/
|
2022-10-18 18:22:07 +00:00
|
|
|
if (is_access_to_paths_allowed(
|
|
|
|
dom, &mnt_dir, access_request_parent1, &layer_masks_parent1,
|
|
|
|
old_dentry, access_request_parent2, &layer_masks_parent2,
|
|
|
|
exchange ? new_dentry : NULL))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This prioritizes EACCES over EXDEV for all actions, including
|
|
|
|
* renames with RENAME_EXCHANGE.
|
|
|
|
*/
|
|
|
|
if (likely(is_eacces(&layer_masks_parent1, access_request_parent1) ||
|
|
|
|
is_eacces(&layer_masks_parent2, access_request_parent2)))
|
|
|
|
return -EACCES;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Gracefully forbids reparenting if the destination directory
|
|
|
|
* hierarchy is not a superset of restrictions of the source directory
|
|
|
|
* hierarchy, or if LANDLOCK_ACCESS_FS_REFER is not allowed by the
|
|
|
|
* source or the destination.
|
|
|
|
*/
|
|
|
|
return -EXDEV;
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
}
|
|
|
|
|
2021-04-22 15:41:17 +00:00
|
|
|
/* Inode hooks */
|
|
|
|
|
2024-07-09 23:43:06 +00:00
|
|
|
static void hook_inode_free_security_rcu(void *inode_security)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
2024-07-09 23:43:06 +00:00
|
|
|
struct landlock_inode_security *inode_sec;
|
|
|
|
|
2021-04-22 15:41:17 +00:00
|
|
|
/*
|
|
|
|
* All inodes must already have been untied from their object by
|
|
|
|
* release_inode() or hook_sb_delete().
|
|
|
|
*/
|
2024-07-09 23:43:06 +00:00
|
|
|
inode_sec = inode_security + landlock_blob_sizes.lbs_inode;
|
|
|
|
WARN_ON_ONCE(inode_sec->object);
|
2021-04-22 15:41:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Super-block hooks */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Release the inodes used in a security policy.
|
|
|
|
*
|
|
|
|
* Cf. fsnotify_unmount_inodes() and invalidate_inodes()
|
|
|
|
*/
|
|
|
|
static void hook_sb_delete(struct super_block *const sb)
|
|
|
|
{
|
|
|
|
struct inode *inode, *prev_inode = NULL;
|
|
|
|
|
|
|
|
if (!landlock_initialized)
|
|
|
|
return;
|
|
|
|
|
|
|
|
spin_lock(&sb->s_inode_list_lock);
|
|
|
|
list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
|
|
|
|
struct landlock_object *object;
|
|
|
|
|
|
|
|
/* Only handles referenced inodes. */
|
|
|
|
if (!atomic_read(&inode->i_count))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Protects against concurrent modification of inode (e.g.
|
|
|
|
* from get_inode_object()).
|
|
|
|
*/
|
|
|
|
spin_lock(&inode->i_lock);
|
|
|
|
/*
|
|
|
|
* Checks I_FREEING and I_WILL_FREE to protect against a race
|
|
|
|
* condition when release_inode() just called iput(), which
|
|
|
|
* could lead to a NULL dereference of inode->security or a
|
|
|
|
* second call to iput() for the same Landlock object. Also
|
|
|
|
* checks I_NEW because such inode cannot be tied to an object.
|
|
|
|
*/
|
|
|
|
if (inode->i_state & (I_FREEING | I_WILL_FREE | I_NEW)) {
|
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
object = rcu_dereference(landlock_inode(inode)->object);
|
|
|
|
if (!object) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
/* Keeps a reference to this inode until the next loop walk. */
|
|
|
|
__iget(inode);
|
|
|
|
spin_unlock(&inode->i_lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there is no concurrent release_inode() ongoing, then we
|
|
|
|
* are in charge of calling iput() on this inode, otherwise we
|
|
|
|
* will just wait for it to finish.
|
|
|
|
*/
|
|
|
|
spin_lock(&object->lock);
|
|
|
|
if (object->underobj == inode) {
|
|
|
|
object->underobj = NULL;
|
|
|
|
spin_unlock(&object->lock);
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Because object->underobj was not NULL,
|
|
|
|
* release_inode() and get_inode_object() guarantee
|
|
|
|
* that it is safe to reset
|
|
|
|
* landlock_inode(inode)->object while it is not NULL.
|
|
|
|
* It is therefore not necessary to lock inode->i_lock.
|
|
|
|
*/
|
|
|
|
rcu_assign_pointer(landlock_inode(inode)->object, NULL);
|
|
|
|
/*
|
|
|
|
* At this point, we own the ihold() reference that was
|
|
|
|
* originally set up by get_inode_object() and the
|
|
|
|
* __iget() reference that we just set in this loop
|
|
|
|
* walk. Therefore the following call to iput() will
|
|
|
|
* not sleep nor drop the inode because there is now at
|
|
|
|
* least two references to it.
|
|
|
|
*/
|
|
|
|
iput(inode);
|
|
|
|
} else {
|
|
|
|
spin_unlock(&object->lock);
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (prev_inode) {
|
|
|
|
/*
|
|
|
|
* At this point, we still own the __iget() reference
|
|
|
|
* that we just set in this loop walk. Therefore we
|
|
|
|
* can drop the list lock and know that the inode won't
|
|
|
|
* disappear from under us until the next loop walk.
|
|
|
|
*/
|
|
|
|
spin_unlock(&sb->s_inode_list_lock);
|
|
|
|
/*
|
|
|
|
* We can now actually put the inode reference from the
|
|
|
|
* previous loop walk, which is not needed anymore.
|
|
|
|
*/
|
|
|
|
iput(prev_inode);
|
|
|
|
cond_resched();
|
|
|
|
spin_lock(&sb->s_inode_list_lock);
|
|
|
|
}
|
|
|
|
prev_inode = inode;
|
|
|
|
}
|
|
|
|
spin_unlock(&sb->s_inode_list_lock);
|
|
|
|
|
|
|
|
/* Puts the inode reference from the last loop walk, if any. */
|
|
|
|
if (prev_inode)
|
|
|
|
iput(prev_inode);
|
|
|
|
/* Waits for pending iput() in release_inode(). */
|
2022-05-06 16:05:08 +00:00
|
|
|
wait_var_event(&landlock_superblock(sb)->inode_refs,
|
|
|
|
!atomic_long_read(&landlock_superblock(sb)->inode_refs));
|
2021-04-22 15:41:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Because a Landlock security policy is defined according to the filesystem
|
|
|
|
* topology (i.e. the mount namespace), changing it may grant access to files
|
|
|
|
* not previously allowed.
|
|
|
|
*
|
|
|
|
* To make it simple, deny any filesystem topology modification by landlocked
|
|
|
|
* processes. Non-landlocked processes may still change the namespace of a
|
|
|
|
* landlocked process, but this kind of threat must be handled by a system-wide
|
|
|
|
* access-control security policy.
|
|
|
|
*
|
|
|
|
* This could be lifted in the future if Landlock can safely handle mount
|
|
|
|
* namespace updates requested by a landlocked process. Indeed, we could
|
|
|
|
* update the current domain (which is currently read-only) by taking into
|
|
|
|
* account the accesses of the source and the destination of a new mount point.
|
|
|
|
* However, it would also require to make all the child domains dynamically
|
|
|
|
* inherit these new constraints. Anyway, for backward compatibility reasons,
|
|
|
|
* a dedicated user space option would be required (e.g. as a ruleset flag).
|
|
|
|
*/
|
|
|
|
static int hook_sb_mount(const char *const dev_name,
|
2022-05-06 16:05:08 +00:00
|
|
|
const struct path *const path, const char *const type,
|
|
|
|
const unsigned long flags, void *const data)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
2023-10-26 01:47:41 +00:00
|
|
|
if (!get_current_fs_domain())
|
2021-04-22 15:41:17 +00:00
|
|
|
return 0;
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hook_move_mount(const struct path *const from_path,
|
2022-05-06 16:05:08 +00:00
|
|
|
const struct path *const to_path)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
2023-10-26 01:47:41 +00:00
|
|
|
if (!get_current_fs_domain())
|
2021-04-22 15:41:17 +00:00
|
|
|
return 0;
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Removing a mount point may reveal a previously hidden file hierarchy, which
|
|
|
|
* may then grant access to files, which may have previously been forbidden.
|
|
|
|
*/
|
|
|
|
static int hook_sb_umount(struct vfsmount *const mnt, const int flags)
|
|
|
|
{
|
2023-10-26 01:47:41 +00:00
|
|
|
if (!get_current_fs_domain())
|
2021-04-22 15:41:17 +00:00
|
|
|
return 0;
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hook_sb_remount(struct super_block *const sb, void *const mnt_opts)
|
|
|
|
{
|
2023-10-26 01:47:41 +00:00
|
|
|
if (!get_current_fs_domain())
|
2021-04-22 15:41:17 +00:00
|
|
|
return 0;
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* pivot_root(2), like mount(2), changes the current mount namespace. It must
|
|
|
|
* then be forbidden for a landlocked process.
|
|
|
|
*
|
|
|
|
* However, chroot(2) may be allowed because it only changes the relative root
|
|
|
|
* directory of the current process. Moreover, it can be used to restrict the
|
|
|
|
* view of the filesystem.
|
|
|
|
*/
|
|
|
|
static int hook_sb_pivotroot(const struct path *const old_path,
|
2022-05-06 16:05:08 +00:00
|
|
|
const struct path *const new_path)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
2023-10-26 01:47:41 +00:00
|
|
|
if (!get_current_fs_domain())
|
2021-04-22 15:41:17 +00:00
|
|
|
return 0;
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Path hooks */
|
|
|
|
|
|
|
|
static int hook_path_link(struct dentry *const old_dentry,
|
2022-05-06 16:05:08 +00:00
|
|
|
const struct path *const new_dir,
|
|
|
|
struct dentry *const new_dentry)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
return current_check_refer_path(old_dentry, new_dir, new_dentry, false,
|
|
|
|
false);
|
2021-04-22 15:41:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int hook_path_rename(const struct path *const old_dir,
|
2022-05-06 16:05:08 +00:00
|
|
|
struct dentry *const old_dentry,
|
|
|
|
const struct path *const new_dir,
|
2022-05-06 16:10:56 +00:00
|
|
|
struct dentry *const new_dentry,
|
|
|
|
const unsigned int flags)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER
Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers
to allow sandboxed processes to link and rename files from and to a
specific set of file hierarchies. This access right should be composed
with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename,
and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This
lift a Landlock limitation that always denied changing the parent of an
inode.
Renaming or linking to the same directory is still always allowed,
whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not
considered a threat to user data.
However, creating multiple links or renaming to a different parent
directory may lead to privilege escalations if not handled properly.
Indeed, we must be sure that the source doesn't gain more privileges by
being accessible from the destination. This is handled by making sure
that the source hierarchy (including the referenced file or directory
itself) restricts at least as much the destination hierarchy. If it is
not the case, an EXDEV error is returned, making it potentially possible
for user space to copy the file hierarchy instead of moving or linking
it.
Instead of creating different access rights for the source and the
destination, we choose to make it simple and consistent for users.
Indeed, considering the previous constraint, it would be weird to
require such destination access right to be also granted to the source
(to make it a superset). Moreover, RENAME_EXCHANGE would also add to
the confusion because of paths being both a source and a destination.
See the provided documentation for additional details.
New tests are provided with a following commit.
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net
2022-05-06 16:10:57 +00:00
|
|
|
/* old_dir refers to old_dentry->d_parent and new_dir->mnt */
|
|
|
|
return current_check_refer_path(old_dentry, new_dir, new_dentry, true,
|
|
|
|
!!(flags & RENAME_EXCHANGE));
|
2021-04-22 15:41:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int hook_path_mkdir(const struct path *const dir,
|
2022-05-06 16:05:08 +00:00
|
|
|
struct dentry *const dentry, const umode_t mode)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
|
|
|
return current_check_access_path(dir, LANDLOCK_ACCESS_FS_MAKE_DIR);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hook_path_mknod(const struct path *const dir,
|
2022-05-06 16:05:08 +00:00
|
|
|
struct dentry *const dentry, const umode_t mode,
|
|
|
|
const unsigned int dev)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
2023-10-26 01:47:41 +00:00
|
|
|
const struct landlock_ruleset *const dom = get_current_fs_domain();
|
2021-04-22 15:41:17 +00:00
|
|
|
|
|
|
|
if (!dom)
|
|
|
|
return 0;
|
|
|
|
return check_access_path(dom, dir, get_mode_access(mode));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hook_path_symlink(const struct path *const dir,
|
2022-05-06 16:05:08 +00:00
|
|
|
struct dentry *const dentry,
|
|
|
|
const char *const old_name)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
|
|
|
return current_check_access_path(dir, LANDLOCK_ACCESS_FS_MAKE_SYM);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hook_path_unlink(const struct path *const dir,
|
2022-05-06 16:05:08 +00:00
|
|
|
struct dentry *const dentry)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
|
|
|
return current_check_access_path(dir, LANDLOCK_ACCESS_FS_REMOVE_FILE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hook_path_rmdir(const struct path *const dir,
|
2022-05-06 16:05:08 +00:00
|
|
|
struct dentry *const dentry)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
|
|
|
return current_check_access_path(dir, LANDLOCK_ACCESS_FS_REMOVE_DIR);
|
|
|
|
}
|
|
|
|
|
2022-10-18 18:22:09 +00:00
|
|
|
static int hook_path_truncate(const struct path *const path)
|
|
|
|
{
|
|
|
|
return current_check_access_path(path, LANDLOCK_ACCESS_FS_TRUNCATE);
|
|
|
|
}
|
|
|
|
|
2021-04-22 15:41:17 +00:00
|
|
|
/* File hooks */
|
|
|
|
|
2022-10-18 18:22:09 +00:00
|
|
|
/**
|
|
|
|
* get_required_file_open_access - Get access needed to open a file
|
|
|
|
*
|
|
|
|
* @file: File being opened.
|
|
|
|
*
|
|
|
|
* Returns the access rights that are required for opening the given file,
|
|
|
|
* depending on the file type and open mode.
|
|
|
|
*/
|
2023-12-08 15:51:13 +00:00
|
|
|
static access_mask_t
|
2022-10-18 18:22:09 +00:00
|
|
|
get_required_file_open_access(const struct file *const file)
|
2021-04-22 15:41:17 +00:00
|
|
|
{
|
2022-05-06 16:10:51 +00:00
|
|
|
access_mask_t access = 0;
|
2021-04-22 15:41:17 +00:00
|
|
|
|
|
|
|
if (file->f_mode & FMODE_READ) {
|
|
|
|
/* A directory can only be opened in read mode. */
|
|
|
|
if (S_ISDIR(file_inode(file)->i_mode))
|
|
|
|
return LANDLOCK_ACCESS_FS_READ_DIR;
|
|
|
|
access = LANDLOCK_ACCESS_FS_READ_FILE;
|
|
|
|
}
|
|
|
|
if (file->f_mode & FMODE_WRITE)
|
|
|
|
access |= LANDLOCK_ACCESS_FS_WRITE_FILE;
|
|
|
|
/* __FMODE_EXEC is indeed part of f_flags, not f_mode. */
|
|
|
|
if (file->f_flags & __FMODE_EXEC)
|
|
|
|
access |= LANDLOCK_ACCESS_FS_EXECUTE;
|
|
|
|
return access;
|
|
|
|
}
|
|
|
|
|
2022-10-18 18:22:09 +00:00
|
|
|
static int hook_file_alloc_security(struct file *const file)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Grants all access rights, even if most of them are not checked later
|
|
|
|
* on. It is more consistent.
|
|
|
|
*
|
|
|
|
* Notably, file descriptors for regular files can also be acquired
|
|
|
|
* without going through the file_open hook, for example when using
|
|
|
|
* memfd_create(2).
|
|
|
|
*/
|
|
|
|
landlock_file(file)->allowed_access = LANDLOCK_MASK_ACCESS_FS;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
static bool is_device(const struct file *const file)
|
|
|
|
{
|
|
|
|
const struct inode *inode = file_inode(file);
|
|
|
|
|
|
|
|
return S_ISBLK(inode->i_mode) || S_ISCHR(inode->i_mode);
|
|
|
|
}
|
|
|
|
|
2021-04-22 15:41:17 +00:00
|
|
|
static int hook_file_open(struct file *const file)
|
|
|
|
{
|
2022-10-18 18:22:09 +00:00
|
|
|
layer_mask_t layer_masks[LANDLOCK_NUM_ACCESS_FS] = {};
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
access_mask_t open_access_request, full_access_request, allowed_access,
|
|
|
|
optional_access;
|
2024-03-07 09:52:03 +00:00
|
|
|
const struct landlock_ruleset *const dom =
|
|
|
|
get_fs_domain(landlock_cred(file->f_cred)->domain);
|
2021-04-22 15:41:17 +00:00
|
|
|
|
|
|
|
if (!dom)
|
|
|
|
return 0;
|
2022-10-18 18:22:09 +00:00
|
|
|
|
2021-04-22 15:41:17 +00:00
|
|
|
/*
|
2022-10-18 18:22:09 +00:00
|
|
|
* Because a file may be opened with O_PATH, get_required_file_open_access()
|
|
|
|
* may return 0. This case will be handled with a future Landlock
|
2021-04-22 15:41:17 +00:00
|
|
|
* evolution.
|
|
|
|
*/
|
2022-10-18 18:22:09 +00:00
|
|
|
open_access_request = get_required_file_open_access(file);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We look up more access than what we immediately need for open(), so
|
|
|
|
* that we can later authorize operations on opened files.
|
|
|
|
*/
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
optional_access = LANDLOCK_ACCESS_FS_TRUNCATE;
|
|
|
|
if (is_device(file))
|
|
|
|
optional_access |= LANDLOCK_ACCESS_FS_IOCTL_DEV;
|
|
|
|
|
2022-10-18 18:22:09 +00:00
|
|
|
full_access_request = open_access_request | optional_access;
|
|
|
|
|
|
|
|
if (is_access_to_paths_allowed(
|
|
|
|
dom, &file->f_path,
|
2023-10-26 01:47:44 +00:00
|
|
|
landlock_init_layer_masks(dom, full_access_request,
|
2023-10-26 01:47:45 +00:00
|
|
|
&layer_masks, LANDLOCK_KEY_INODE),
|
2022-10-18 18:22:09 +00:00
|
|
|
&layer_masks, NULL, 0, NULL, NULL)) {
|
|
|
|
allowed_access = full_access_request;
|
|
|
|
} else {
|
|
|
|
unsigned long access_bit;
|
|
|
|
const unsigned long access_req = full_access_request;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the actual allowed access rights from layer_masks.
|
|
|
|
* Add each access right to allowed_access which has not been
|
|
|
|
* vetoed by any layer.
|
|
|
|
*/
|
|
|
|
allowed_access = 0;
|
|
|
|
for_each_set_bit(access_bit, &access_req,
|
|
|
|
ARRAY_SIZE(layer_masks)) {
|
|
|
|
if (!layer_masks[access_bit])
|
|
|
|
allowed_access |= BIT_ULL(access_bit);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For operations on already opened files (i.e. ftruncate()), it is the
|
|
|
|
* access rights at the time of open() which decide whether the
|
|
|
|
* operation is permitted. Therefore, we record the relevant subset of
|
|
|
|
* file access rights in the opened struct file.
|
|
|
|
*/
|
|
|
|
landlock_file(file)->allowed_access = allowed_access;
|
|
|
|
|
|
|
|
if ((open_access_request & allowed_access) == open_access_request)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return -EACCES;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hook_file_truncate(struct file *const file)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Allows truncation if the truncate right was available at the time of
|
|
|
|
* opening the file, to get a consistent access check as for read, write
|
|
|
|
* and execute operations.
|
|
|
|
*
|
|
|
|
* Note: For checks done based on the file's Landlock allowed access, we
|
|
|
|
* enforce them independently of whether the current thread is in a
|
|
|
|
* Landlock domain, so that open files passed between independent
|
|
|
|
* processes retain their behaviour.
|
|
|
|
*/
|
|
|
|
if (landlock_file(file)->allowed_access & LANDLOCK_ACCESS_FS_TRUNCATE)
|
|
|
|
return 0;
|
|
|
|
return -EACCES;
|
2021-04-22 15:41:17 +00:00
|
|
|
}
|
|
|
|
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
static int hook_file_ioctl(struct file *file, unsigned int cmd,
|
|
|
|
unsigned long arg)
|
|
|
|
{
|
|
|
|
access_mask_t allowed_access = landlock_file(file)->allowed_access;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It is the access rights at the time of opening the file which
|
|
|
|
* determine whether IOCTL can be used on the opened file later.
|
|
|
|
*
|
|
|
|
* The access right is attached to the opened file in hook_file_open().
|
|
|
|
*/
|
|
|
|
if (allowed_access & LANDLOCK_ACCESS_FS_IOCTL_DEV)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!is_device(file))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (is_masked_device_ioctl(cmd))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return -EACCES;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int hook_file_ioctl_compat(struct file *file, unsigned int cmd,
|
|
|
|
unsigned long arg)
|
|
|
|
{
|
|
|
|
access_mask_t allowed_access = landlock_file(file)->allowed_access;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It is the access rights at the time of opening the file which
|
|
|
|
* determine whether IOCTL can be used on the opened file later.
|
|
|
|
*
|
|
|
|
* The access right is attached to the opened file in hook_file_open().
|
|
|
|
*/
|
|
|
|
if (allowed_access & LANDLOCK_ACCESS_FS_IOCTL_DEV)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!is_device(file))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (is_masked_device_ioctl_compat(cmd))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return -EACCES;
|
|
|
|
}
|
|
|
|
|
landlock: Add signal scoping
Currently, a sandbox process is not restricted to sending a signal (e.g.
SIGKILL) to a process outside the sandbox environment. The ability to
send a signal for a sandboxed process should be scoped the same way
abstract UNIX sockets are scoped. Therefore, we extend the "scoped"
field in a ruleset with LANDLOCK_SCOPE_SIGNAL to specify that a ruleset
will deny sending any signal from within a sandbox process to its parent
(i.e. any parent sandbox or non-sandboxed processes).
This patch adds file_set_fowner and file_free_security hooks to set and
release a pointer to the file owner's domain. This pointer, fown_domain
in landlock_file_security will be used in file_send_sigiotask to check
if the process can send a signal.
The ruleset_with_unknown_scope test is updated to support
LANDLOCK_SCOPE_SIGNAL.
This depends on two new changes:
- commit 1934b212615d ("file: reclaim 24 bytes from f_owner"): replace
container_of(fown, struct file, f_owner) with fown->file .
- commit 26f204380a3c ("fs: Fix file_set_fowner LSM hook
inconsistencies"): lock before calling the hook.
Signed-off-by: Tahera Fahimi <fahimitahera@gmail.com>
Closes: https://github.com/landlock-lsm/linux/issues/8
Link: https://lore.kernel.org/r/df2b4f880a2ed3042992689a793ea0951f6798a5.1725657727.git.fahimitahera@gmail.com
[mic: Update landlock_get_current_domain()'s return type, improve and
fix locking in hook_file_set_fowner(), simplify and fix sleepable call
and locking issue in hook_file_send_sigiotask() and rebase on the latest
VFS tree, simplify hook_task_kill() and quickly return when not
sandboxed, improve comments, rename LANDLOCK_SCOPED_SIGNAL]
Co-developed-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-09-06 21:30:03 +00:00
|
|
|
static void hook_file_set_fowner(struct file *file)
|
|
|
|
{
|
|
|
|
struct landlock_ruleset *new_dom, *prev_dom;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Lock already held by __f_setown(), see commit 26f204380a3c ("fs: Fix
|
|
|
|
* file_set_fowner LSM hook inconsistencies").
|
|
|
|
*/
|
|
|
|
lockdep_assert_held(&file_f_owner(file)->lock);
|
|
|
|
new_dom = landlock_get_current_domain();
|
|
|
|
landlock_get_ruleset(new_dom);
|
|
|
|
prev_dom = landlock_file(file)->fown_domain;
|
|
|
|
landlock_file(file)->fown_domain = new_dom;
|
|
|
|
|
|
|
|
/* Called in an RCU read-side critical section. */
|
|
|
|
landlock_put_ruleset_deferred(prev_dom);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void hook_file_free_security(struct file *file)
|
|
|
|
{
|
|
|
|
landlock_put_ruleset_deferred(landlock_file(file)->fown_domain);
|
|
|
|
}
|
|
|
|
|
selinux: remove the runtime disable functionality
After working with the larger SELinux-based distros for several
years, we're finally at a place where we can disable the SELinux
runtime disable functionality. The existing kernel deprecation
notice explains the functionality and why we want to remove it:
The selinuxfs "disable" node allows SELinux to be disabled at
runtime prior to a policy being loaded into the kernel. If
disabled via this mechanism, SELinux will remain disabled until
the system is rebooted.
The preferred method of disabling SELinux is via the "selinux=0"
boot parameter, but the selinuxfs "disable" node was created to
make it easier for systems with primitive bootloaders that did not
allow for easy modification of the kernel command line.
Unfortunately, allowing for SELinux to be disabled at runtime makes
it difficult to secure the kernel's LSM hooks using the
"__ro_after_init" feature.
It is that last sentence, mentioning the '__ro_after_init' hardening,
which is the real motivation for this change, and if you look at the
diffstat you'll see that the impact of this patch reaches across all
the different LSMs, helping prevent tampering at the LSM hook level.
From a SELinux perspective, it is important to note that if you
continue to disable SELinux via "/etc/selinux/config" it may appear
that SELinux is disabled, but it is simply in an uninitialized state.
If you load a policy with `load_policy -i`, you will see SELinux
come alive just as if you had loaded the policy during early-boot.
It is also worth noting that the "/sys/fs/selinux/disable" file is
always writable now, regardless of the Kconfig settings, but writing
to the file has no effect on the system, other than to display an
error on the console if a non-zero/true value is written.
Finally, in the several years where we have been working on
deprecating this functionality, there has only been one instance of
someone mentioning any user visible breakage. In this particular
case it was an individual's kernel test system, and the workaround
documented in the deprecation notice ("selinux=0" on the kernel
command line) resolved the issue without problem.
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
2023-03-17 16:43:07 +00:00
|
|
|
static struct security_hook_list landlock_hooks[] __ro_after_init = {
|
2024-07-09 23:43:06 +00:00
|
|
|
LSM_HOOK_INIT(inode_free_security_rcu, hook_inode_free_security_rcu),
|
2021-04-22 15:41:17 +00:00
|
|
|
|
|
|
|
LSM_HOOK_INIT(sb_delete, hook_sb_delete),
|
|
|
|
LSM_HOOK_INIT(sb_mount, hook_sb_mount),
|
|
|
|
LSM_HOOK_INIT(move_mount, hook_move_mount),
|
|
|
|
LSM_HOOK_INIT(sb_umount, hook_sb_umount),
|
|
|
|
LSM_HOOK_INIT(sb_remount, hook_sb_remount),
|
|
|
|
LSM_HOOK_INIT(sb_pivotroot, hook_sb_pivotroot),
|
|
|
|
|
|
|
|
LSM_HOOK_INIT(path_link, hook_path_link),
|
|
|
|
LSM_HOOK_INIT(path_rename, hook_path_rename),
|
|
|
|
LSM_HOOK_INIT(path_mkdir, hook_path_mkdir),
|
|
|
|
LSM_HOOK_INIT(path_mknod, hook_path_mknod),
|
|
|
|
LSM_HOOK_INIT(path_symlink, hook_path_symlink),
|
|
|
|
LSM_HOOK_INIT(path_unlink, hook_path_unlink),
|
|
|
|
LSM_HOOK_INIT(path_rmdir, hook_path_rmdir),
|
2022-10-18 18:22:09 +00:00
|
|
|
LSM_HOOK_INIT(path_truncate, hook_path_truncate),
|
2021-04-22 15:41:17 +00:00
|
|
|
|
2022-10-18 18:22:09 +00:00
|
|
|
LSM_HOOK_INIT(file_alloc_security, hook_file_alloc_security),
|
2021-04-22 15:41:17 +00:00
|
|
|
LSM_HOOK_INIT(file_open, hook_file_open),
|
2022-10-18 18:22:09 +00:00
|
|
|
LSM_HOOK_INIT(file_truncate, hook_file_truncate),
|
landlock: Add IOCTL access right for character and block devices
Introduces the LANDLOCK_ACCESS_FS_IOCTL_DEV right
and increments the Landlock ABI version to 5.
This access right applies to device-custom IOCTL commands
when they are invoked on block or character device files.
Like the truncate right, this right is associated with a file
descriptor at the time of open(2), and gets respected even when the
file descriptor is used outside of the thread which it was originally
opened in.
Therefore, a newly enabled Landlock policy does not apply to file
descriptors which are already open.
If the LANDLOCK_ACCESS_FS_IOCTL_DEV right is handled, only a small
number of safe IOCTL commands will be permitted on newly opened device
files. These include FIOCLEX, FIONCLEX, FIONBIO and FIOASYNC, as well
as other IOCTL commands for regular files which are implemented in
fs/ioctl.c.
Noteworthy scenarios which require special attention:
TTY devices are often passed into a process from the parent process,
and so a newly enabled Landlock policy does not retroactively apply to
them automatically. In the past, TTY devices have often supported
IOCTL commands like TIOCSTI and some TIOCLINUX subcommands, which were
letting callers control the TTY input buffer (and simulate
keypresses). This should be restricted to CAP_SYS_ADMIN programs on
modern kernels though.
Known limitations:
The LANDLOCK_ACCESS_FS_IOCTL_DEV access right is a coarse-grained
control over IOCTL commands.
Landlock users may use path-based restrictions in combination with
their knowledge about the file system layout to control what IOCTLs
can be done.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240419161122.2023765-2-gnoack@google.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-04-19 16:11:12 +00:00
|
|
|
LSM_HOOK_INIT(file_ioctl, hook_file_ioctl),
|
|
|
|
LSM_HOOK_INIT(file_ioctl_compat, hook_file_ioctl_compat),
|
landlock: Add signal scoping
Currently, a sandbox process is not restricted to sending a signal (e.g.
SIGKILL) to a process outside the sandbox environment. The ability to
send a signal for a sandboxed process should be scoped the same way
abstract UNIX sockets are scoped. Therefore, we extend the "scoped"
field in a ruleset with LANDLOCK_SCOPE_SIGNAL to specify that a ruleset
will deny sending any signal from within a sandbox process to its parent
(i.e. any parent sandbox or non-sandboxed processes).
This patch adds file_set_fowner and file_free_security hooks to set and
release a pointer to the file owner's domain. This pointer, fown_domain
in landlock_file_security will be used in file_send_sigiotask to check
if the process can send a signal.
The ruleset_with_unknown_scope test is updated to support
LANDLOCK_SCOPE_SIGNAL.
This depends on two new changes:
- commit 1934b212615d ("file: reclaim 24 bytes from f_owner"): replace
container_of(fown, struct file, f_owner) with fown->file .
- commit 26f204380a3c ("fs: Fix file_set_fowner LSM hook
inconsistencies"): lock before calling the hook.
Signed-off-by: Tahera Fahimi <fahimitahera@gmail.com>
Closes: https://github.com/landlock-lsm/linux/issues/8
Link: https://lore.kernel.org/r/df2b4f880a2ed3042992689a793ea0951f6798a5.1725657727.git.fahimitahera@gmail.com
[mic: Update landlock_get_current_domain()'s return type, improve and
fix locking in hook_file_set_fowner(), simplify and fix sleepable call
and locking issue in hook_file_send_sigiotask() and rebase on the latest
VFS tree, simplify hook_task_kill() and quickly return when not
sandboxed, improve comments, rename LANDLOCK_SCOPED_SIGNAL]
Co-developed-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-09-06 21:30:03 +00:00
|
|
|
LSM_HOOK_INIT(file_set_fowner, hook_file_set_fowner),
|
|
|
|
LSM_HOOK_INIT(file_free_security, hook_file_free_security),
|
2021-04-22 15:41:17 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
__init void landlock_add_fs_hooks(void)
|
|
|
|
{
|
|
|
|
security_add_hooks(landlock_hooks, ARRAY_SIZE(landlock_hooks),
|
2023-09-12 20:56:46 +00:00
|
|
|
&landlock_lsmid);
|
2021-04-22 15:41:17 +00:00
|
|
|
}
|
2024-01-18 11:36:32 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_SECURITY_LANDLOCK_KUNIT_TEST
|
|
|
|
|
|
|
|
/* clang-format off */
|
|
|
|
static struct kunit_case test_cases[] = {
|
|
|
|
KUNIT_CASE(test_no_more_access),
|
|
|
|
KUNIT_CASE(test_scope_to_request_with_exec_none),
|
|
|
|
KUNIT_CASE(test_scope_to_request_with_exec_some),
|
|
|
|
KUNIT_CASE(test_scope_to_request_without_access),
|
|
|
|
KUNIT_CASE(test_is_eacces_with_none),
|
|
|
|
KUNIT_CASE(test_is_eacces_with_refer),
|
|
|
|
KUNIT_CASE(test_is_eacces_with_write),
|
|
|
|
{}
|
|
|
|
};
|
|
|
|
/* clang-format on */
|
|
|
|
|
|
|
|
static struct kunit_suite test_suite = {
|
|
|
|
.name = "landlock_fs",
|
|
|
|
.test_cases = test_cases,
|
|
|
|
};
|
|
|
|
|
|
|
|
kunit_test_suite(test_suite);
|
|
|
|
|
|
|
|
#endif /* CONFIG_SECURITY_LANDLOCK_KUNIT_TEST */
|