* [RFC PATCH v1 1/3] landlock: Add landlock_read_domain_id()
2025-01-31 16:34 [RFC PATCH v1 0/3] Expose Landlock domain IDs via pidfd Mickaël Salaün
@ 2025-01-31 16:34 ` Mickaël Salaün
2025-01-31 16:34 ` [RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN Mickaël Salaün
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Mickaël Salaün @ 2025-01-31 16:34 UTC (permalink / raw)
To: Christian Brauner, Günther Noack
Cc: Mickaël Salaün, Charles Zaffery, Daniel Burgener,
Francis Laniel, James Morris, Jann Horn, Jeff Xu, Kees Cook,
Luca Boccassi, Mikhail Ivanov, Praveen K Paladugu, Robert Salvet,
Shervin Oloumi, Tyler Hicks, linux-kernel, linux-security-module
This public landlock_read_domain_id() helper will be used in the next
commit by the PIDFD_GET_INFO IOCTL to read a task's domain ID.
A task is only allowed to get information about its nested domains.
Being able to read tasks' domain IDs is useful for telemetry, debugging,
and tests. It enables users:
- to know if a task is well sandboxed;
- to know which tasks are part of the same sandbox;
- to map Landlock audit logs to running processes.
Future changes will leverage this feature to improve Landlock
observability.
Landlock domain IDs are now always generated at domain creation time.
Cc: Christian Brauner <brauner@kernel.org>
Cc: Günther Noack <gnoack@google.com>
Cc: Luca Boccassi <luca.boccassi@gmail.com>
Cc: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20250131163447.1140564-2-mic@digikod.net
---
include/linux/landlock.h | 26 +++++++++++++
security/landlock/Makefile | 12 ++++--
security/landlock/domain.c | 2 -
security/landlock/domain.h | 8 ++--
security/landlock/ruleset.c | 2 +
security/landlock/syscalls.c | 75 ++++++++++++++++++++++++++++++++++++
6 files changed, 116 insertions(+), 9 deletions(-)
create mode 100644 include/linux/landlock.h
diff --git a/include/linux/landlock.h b/include/linux/landlock.h
new file mode 100644
index 000000000000..a091deee9ad7
--- /dev/null
+++ b/include/linux/landlock.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Landlock public helpers
+ *
+ * Copyright © 2025 Microsoft Corporation
+ */
+
+#include <linux/cred.h>
+#include <linux/sched.h>
+
+#ifdef CONFIG_SECURITY_LANDLOCK
+
+int landlock_read_domain_id(const struct cred *const cred,
+ struct task_struct *const task, const bool last,
+ u64 *const id);
+
+#else /* CONFIG_SECURITY_LANDLOCK */
+
+static inline int landlock_read_domain_id(const struct cred *const cred,
+ struct task_struct *const task,
+ const bool last, u64 *const id)
+{
+ return -EOPNOTSUPP;
+}
+
+#endif /* CONFIG_SECURITY_LANDLOCK */
diff --git a/security/landlock/Makefile b/security/landlock/Makefile
index 3160c2bdac1d..5db653a1717e 100644
--- a/security/landlock/Makefile
+++ b/security/landlock/Makefile
@@ -1,11 +1,17 @@
obj-$(CONFIG_SECURITY_LANDLOCK) := landlock.o
-landlock-y := setup.o syscalls.o object.o ruleset.o \
- cred.o task.o fs.o
+landlock-y := \
+ setup.o \
+ syscalls.o \
+ object.o \
+ ruleset.o \
+ cred.o \
+ task.o \
+ fs.o \
+ id.o
landlock-$(CONFIG_INET) += net.o
landlock-$(CONFIG_AUDIT) += \
- id.o \
audit.o \
domain.o
diff --git a/security/landlock/domain.c b/security/landlock/domain.c
index 49ccb0f72e53..782cc4ef73e0 100644
--- a/security/landlock/domain.c
+++ b/security/landlock/domain.c
@@ -21,7 +21,6 @@
#include "common.h"
#include "domain.h"
#include "fs.h"
-#include "id.h"
#ifdef CONFIG_AUDIT
@@ -125,7 +124,6 @@ int landlock_init_hierarchy_log(struct landlock_hierarchy *const hierarchy)
return PTR_ERR(details);
hierarchy->details = details;
- hierarchy->id = landlock_get_id_range(1);
hierarchy->log_status = LANDLOCK_LOG_PENDING;
hierarchy->quiet_subdomains = false;
hierarchy->log_cross_exec = false;
diff --git a/security/landlock/domain.h b/security/landlock/domain.h
index 06b213aa7579..3f678caddaff 100644
--- a/security/landlock/domain.h
+++ b/security/landlock/domain.h
@@ -78,6 +78,10 @@ struct landlock_hierarchy {
* Landlock domain.
*/
struct landlock_hierarchy *parent;
+ /**
+ * @id: Landlock domain ID, sets once at domain creation time.
+ */
+ u64 id;
/**
* @usage: Number of potential children domains plus their parent
* domain.
@@ -96,10 +100,6 @@ struct landlock_hierarchy {
* Masked (i.e. never logged) denials are still counted.
*/
atomic64_t num_denials;
- /**
- * @id: Landlock domain ID, sets once at domain creation time.
- */
- u64 id;
/**
* @details: Information about the related domain.
*/
diff --git a/security/landlock/ruleset.c b/security/landlock/ruleset.c
index de41e8bde2e4..e42933361c32 100644
--- a/security/landlock/ruleset.c
+++ b/security/landlock/ruleset.c
@@ -25,6 +25,7 @@
#include "access.h"
#include "audit.h"
#include "domain.h"
+#include "id.h"
#include "limits.h"
#include "object.h"
#include "ruleset.h"
@@ -576,6 +577,7 @@ landlock_merge_ruleset(struct landlock_ruleset *const parent,
if (err)
return ERR_PTR(err);
+ new_dom->hierarchy->id = landlock_get_id_range(1);
return no_free_ptr(new_dom);
}
diff --git a/security/landlock/syscalls.c b/security/landlock/syscalls.c
index 5709a53c4a09..060ac9d52527 100644
--- a/security/landlock/syscalls.c
+++ b/security/landlock/syscalls.c
@@ -16,6 +16,7 @@
#include <linux/err.h>
#include <linux/errno.h>
#include <linux/fs.h>
+#include <linux/landlock.h>
#include <linux/limits.h>
#include <linux/mount.h>
#include <linux/path.h>
@@ -538,3 +539,77 @@ SYSCALL_DEFINE2(landlock_restrict_self, const int, ruleset_fd, const __u32,
return commit_creds(new_cred);
}
+
+/**
+ * landlock_read_domain_id - Read the domain ID of a task
+ *
+ * @cred: The credential used to check permission.
+ * @task: Task to read the domain ID from.
+ * @last: Either get the ID of the last or the closest nested domain relative
+ * to @cred.
+ * @id: Returned domain ID on success.
+ *
+ * @cred is only allowed to get information about its nested domains.
+ *
+ * Any error returned by this function just translates to non-information in a
+ * PIDFD_GET_INFO's PIDFD_INFO_LANDLOCK_LAST_DOMAIN or
+ * PIDFD_INFO_LANDLOCK_FIRST_DOMAIN request.
+ *
+ * Returns: 0 on success, or -errno on error.
+ */
+int landlock_read_domain_id(const struct cred *const cred,
+ struct task_struct *const task, const bool last,
+ u64 *const id)
+{
+ const struct landlock_ruleset *cred_dom, *task_dom;
+ const struct landlock_hierarchy *walker, *prev;
+ bool is_allowed;
+
+ if (!is_initialized())
+ return -EOPNOTSUPP;
+
+ cred_dom = landlock_cred(cred)->domain;
+
+ guard(rcu)();
+ task_dom = landlock_get_task_domain(task);
+
+ /*
+ * Domain introspection is denied to not leak information about the
+ * current restrictions. However, a task can open a pidfd to itself,
+ * sandbox itself, and then read its domain ID from the previously
+ * opened pidfd. This is OK because the task already knows its
+ * sandbox, which might not be the case for its children.
+ *
+ * For consistency wrt sandboxed and non-sandboxed tasks, any task
+ * should get the same result when directly reading its own domain. A
+ * non-sandboxed task requesting to read another non-sandboxed task
+ * should then also be denied (i.e. cred_dom == task_dom == NULL).
+ */
+ if (cred_dom == task_dom)
+ return -EPERM;
+
+ if (!task_dom)
+ return -EPERM;
+
+ /* Reading properties of @cred's nested domains is allowed. */
+ is_allowed = !cred_dom;
+ prev = task_dom->hierarchy;
+ for (walker = prev; walker; walker = walker->parent) {
+ if (cred_dom && walker == cred_dom->hierarchy) {
+ is_allowed = true;
+ break;
+ }
+
+ prev = walker;
+ }
+
+ if (!is_allowed)
+ return -EPERM;
+
+ if (last)
+ *id = task_dom->hierarchy->id;
+ else
+ *id = prev->id;
+
+ return 0;
+}
--
2.48.1
^ permalink raw reply related [flat|nested] 9+ messages in thread* [RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN
2025-01-31 16:34 [RFC PATCH v1 0/3] Expose Landlock domain IDs via pidfd Mickaël Salaün
2025-01-31 16:34 ` [RFC PATCH v1 1/3] landlock: Add landlock_read_domain_id() Mickaël Salaün
@ 2025-01-31 16:34 ` Mickaël Salaün
2025-01-31 19:02 ` Paul Moore
2025-01-31 16:34 ` [RFC PATCH v1 3/3] samples/landlock: Print domain ID Mickaël Salaün
2025-01-31 17:35 ` [RFC PATCH v1 0/3] Expose Landlock domain IDs via pidfd Mickaël Salaün
3 siblings, 1 reply; 9+ messages in thread
From: Mickaël Salaün @ 2025-01-31 16:34 UTC (permalink / raw)
To: Christian Brauner, Günther Noack
Cc: Mickaël Salaün, Charles Zaffery, Daniel Burgener,
Francis Laniel, James Morris, Jann Horn, Jeff Xu, Kees Cook,
Luca Boccassi, Mikhail Ivanov, Praveen K Paladugu, Robert Salvet,
Shervin Oloumi, Tyler Hicks, linux-kernel, linux-security-module
Because Landlock enables users to create nested sandboxes (i.e.
domains), we might need to identify the domain with all restrictions
(latest), or the domain we created (i.e. closest domain). Indeed,
because any process can create its own domain, the latest domain may not
be known by the requester.
The PIDFD_INFO_LANDLOCK_LAST_DOMAIN flag enables user space to get the
latest (i.e. most nested) Landlock domain ID related to a sandboxed
task, if any. The domain ID is set in the pidfd_info's
landlock_last_domain field according to the related mask.
The PIDFD_INFO_LANDLOCK_FIRST_DOMAIN flag enables user space to get the
closest (i.e. first hierarchy relative to the pidfd's credentials)
Landlock domain ID related to a sandboxed task, if any. The domain ID
is set in the pidfd_info's landlock_first_domain field according to the
related mask.
It is only allowed to get information about a Landlock domain if the
task's domain that created the pidfd is a parent of the PID's domain.
Following the object-capability model, the pidfd's credentials are used
instead of the caller's credentials. This makes this command
idenmpotent wrt the referenced process's state.
If Landlock is not supported or if access to this information is denied,
then the IOCTL does not set the PIDFD_INFO_LANDLOCK_*_DOMAIN flag in the
returned mask.
If PIDFD_INFO_LANDLOCK_LAST_DOMAIN or PIDFD_INFO_LANDLOCK_FIRST_DOMAIN
is specified but the provided struct pidfd_info is not large enough to
contain the related field, then -EINVAL is returned.
Cc: Christian Brauner <brauner@kernel.org>
Cc: Günther Noack <gnoack@google.com>
Cc: Luca Boccassi <luca.boccassi@gmail.com>
Cc: Praveen K Paladugu <prapal@linux.microsoft.com>
Closes: https://github.com/landlock-lsm/linux/issues/26
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20250131163447.1140564-3-mic@digikod.net
---
fs/pidfs.c | 24 ++++++++++++++++++++++--
include/uapi/linux/pidfd.h | 4 ++++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/fs/pidfs.c b/fs/pidfs.c
index 049352f973de..4ff5b6c776ce 100644
--- a/fs/pidfs.c
+++ b/fs/pidfs.c
@@ -20,6 +20,7 @@
#include <linux/time_namespace.h>
#include <linux/utsname.h>
#include <net/net_namespace.h>
+#include <linux/landlock.h>
#include "internal.h"
#include "mount.h"
@@ -207,7 +208,8 @@ static __poll_t pidfd_poll(struct file *file, struct poll_table_struct *pts)
return poll_flags;
}
-static long pidfd_info(struct task_struct *task, unsigned int cmd, unsigned long arg)
+static long pidfd_info(const struct cred *cred, struct task_struct *task,
+ unsigned int cmd, unsigned long arg)
{
struct pidfd_info __user *uinfo = (struct pidfd_info __user *)arg;
size_t usize = _IOC_SIZE(cmd);
@@ -227,6 +229,14 @@ static long pidfd_info(struct task_struct *task, unsigned int cmd, unsigned long
if (copy_from_user(&mask, &uinfo->mask, sizeof(mask)))
return -EFAULT;
+ if ((mask & PIDFD_INFO_LANDLOCK_LAST_DOMAIN) &&
+ usize < offsetofend(typeof(*uinfo), landlock_last_domain))
+ return -EINVAL;
+
+ if ((mask & PIDFD_INFO_LANDLOCK_FIRST_DOMAIN) &&
+ usize < offsetofend(typeof(*uinfo), landlock_first_domain))
+ return -EINVAL;
+
c = get_task_cred(task);
if (!c)
return -ESRCH;
@@ -253,6 +263,16 @@ static long pidfd_info(struct task_struct *task, unsigned int cmd, unsigned long
rcu_read_unlock();
#endif
+ if ((mask & PIDFD_INFO_LANDLOCK_LAST_DOMAIN) &&
+ !landlock_read_domain_id(cred, task, true,
+ &kinfo.landlock_last_domain))
+ kinfo.mask |= PIDFD_INFO_LANDLOCK_LAST_DOMAIN;
+
+ if ((mask & PIDFD_INFO_LANDLOCK_FIRST_DOMAIN) &&
+ !landlock_read_domain_id(cred, task, false,
+ &kinfo.landlock_first_domain))
+ kinfo.mask |= PIDFD_INFO_LANDLOCK_FIRST_DOMAIN;
+
/*
* Copy pid/tgid last, to reduce the chances the information might be
* stale. Note that it is not possible to ensure it will be valid as the
@@ -328,7 +348,7 @@ static long pidfd_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
/* Extensible IOCTL that does not open namespace FDs, take a shortcut */
if (_IOC_NR(cmd) == _IOC_NR(PIDFD_GET_INFO))
- return pidfd_info(task, cmd, arg);
+ return pidfd_info(file->f_cred, task, cmd, arg);
if (arg)
return -EINVAL;
diff --git a/include/uapi/linux/pidfd.h b/include/uapi/linux/pidfd.h
index 4540f6301b8c..267991bd266c 100644
--- a/include/uapi/linux/pidfd.h
+++ b/include/uapi/linux/pidfd.h
@@ -20,6 +20,8 @@
#define PIDFD_INFO_PID (1UL << 0) /* Always returned, even if not requested */
#define PIDFD_INFO_CREDS (1UL << 1) /* Always returned, even if not requested */
#define PIDFD_INFO_CGROUPID (1UL << 2) /* Always returned if available, even if not requested */
+#define PIDFD_INFO_LANDLOCK_LAST_DOMAIN (1UL << 3) /* Only returned if requested */
+#define PIDFD_INFO_LANDLOCK_FIRST_DOMAIN (1UL << 4) /* Only returned if requested */
#define PIDFD_INFO_SIZE_VER0 64 /* sizeof first published struct */
@@ -63,6 +65,8 @@ struct pidfd_info {
__u32 fsuid;
__u32 fsgid;
__u32 spare0[1];
+ __u64 landlock_last_domain;
+ __u64 landlock_first_domain;
};
#define PIDFS_IOCTL_MAGIC 0xFF
--
2.48.1
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN
2025-01-31 16:34 ` [RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN Mickaël Salaün
@ 2025-01-31 19:02 ` Paul Moore
2025-02-01 10:28 ` Mickaël Salaün
0 siblings, 1 reply; 9+ messages in thread
From: Paul Moore @ 2025-01-31 19:02 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Christian Brauner, Günther Noack, Charles Zaffery,
Daniel Burgener, Francis Laniel, James Morris, Jann Horn, Jeff Xu,
Kees Cook, Luca Boccassi, Mikhail Ivanov, Praveen K Paladugu,
Robert Salvet, Shervin Oloumi, Tyler Hicks, linux-kernel,
linux-security-module
On Fri, Jan 31, 2025 at 11:43 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> Because Landlock enables users to create nested sandboxes (i.e.
> domains), we might need to identify the domain with all restrictions
> (latest), or the domain we created (i.e. closest domain). Indeed,
> because any process can create its own domain, the latest domain may not
> be known by the requester.
>
> The PIDFD_INFO_LANDLOCK_LAST_DOMAIN flag enables user space to get the
> latest (i.e. most nested) Landlock domain ID related to a sandboxed
> task, if any. The domain ID is set in the pidfd_info's
> landlock_last_domain field according to the related mask.
>
> The PIDFD_INFO_LANDLOCK_FIRST_DOMAIN flag enables user space to get the
> closest (i.e. first hierarchy relative to the pidfd's credentials)
> Landlock domain ID related to a sandboxed task, if any. The domain ID
> is set in the pidfd_info's landlock_first_domain field according to the
> related mask.
>
> It is only allowed to get information about a Landlock domain if the
> task's domain that created the pidfd is a parent of the PID's domain.
> Following the object-capability model, the pidfd's credentials are used
> instead of the caller's credentials. This makes this command
> idenmpotent wrt the referenced process's state.
>
> If Landlock is not supported or if access to this information is denied,
> then the IOCTL does not set the PIDFD_INFO_LANDLOCK_*_DOMAIN flag in the
> returned mask.
>
> If PIDFD_INFO_LANDLOCK_LAST_DOMAIN or PIDFD_INFO_LANDLOCK_FIRST_DOMAIN
> is specified but the provided struct pidfd_info is not large enough to
> contain the related field, then -EINVAL is returned.
>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Günther Noack <gnoack@google.com>
> Cc: Luca Boccassi <luca.boccassi@gmail.com>
> Cc: Praveen K Paladugu <prapal@linux.microsoft.com>
> Closes: https://github.com/landlock-lsm/linux/issues/26
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> Link: https://lore.kernel.org/r/20250131163447.1140564-3-mic@digikod.net
> ---
> fs/pidfs.c | 24 ++++++++++++++++++++++--
> include/uapi/linux/pidfd.h | 4 ++++
> 2 files changed, 26 insertions(+), 2 deletions(-)
While there are exceptions, mostly for legacy things, we try very hard
to avoid having the kernel call directly into a specific LSM,
preferring to use LSM interfaces, both so that all LSMs can benefit
from the change and also so that we can avoid having a lot of very
similar, but LSM-specific, calls in various parts in the kernel.
There is an effort, albeit a slowly moving effort due to interrupts,
to add LSM support via a PIDFS_GET_SECURITY API:
https://lore.kernel.org/linux-security-module/CAHC9VhRV3KcNGRw6_c-97G6w=HKNuEQoUGrfKhsQdWywzDDnBQ@mail.gmail.com/
I don't see any reason why we couldn't support Landlock's domain info
as part of that, the lsm_ctx struct was created to support various
different LSM contexts/attributes. You could either add multiple
lsm_ctx array entries for Landlock, one for each of the domain IDs, or
you could place all of the domain IDs in an expanded lsm_ctx.
Remember the lsm_ctx->ctx field can hold binary blobs and/or you can
expand past the end of lsm_ctx->ctx so long as lsm_ctx->{len,ctx_len}
are set accordingly.
If you want to work on the PIDFS_GET_SECURITY patch(set) as a means to
add Landlock domain ID support, I think that would be great. Luca
provided a basic skeleton in the link above, and I expect you would
have no issue adding the missing LSM bits.
--
paul-moore.com
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN
2025-01-31 19:02 ` Paul Moore
@ 2025-02-01 10:28 ` Mickaël Salaün
2025-02-01 11:09 ` Christian Brauner
2025-02-01 23:48 ` Paul Moore
0 siblings, 2 replies; 9+ messages in thread
From: Mickaël Salaün @ 2025-02-01 10:28 UTC (permalink / raw)
To: Paul Moore
Cc: Christian Brauner, Günther Noack, Charles Zaffery,
Daniel Burgener, Francis Laniel, James Morris, Jann Horn, Jeff Xu,
Kees Cook, Luca Boccassi, Mikhail Ivanov, Praveen K Paladugu,
Robert Salvet, Shervin Oloumi, Tyler Hicks, linux-kernel,
linux-security-module
On Fri, Jan 31, 2025 at 02:02:49PM -0500, Paul Moore wrote:
> On Fri, Jan 31, 2025 at 11:43 AM Mickaël Salaün <mic@digikod.net> wrote:
> >
> > Because Landlock enables users to create nested sandboxes (i.e.
> > domains), we might need to identify the domain with all restrictions
> > (latest), or the domain we created (i.e. closest domain). Indeed,
> > because any process can create its own domain, the latest domain may not
> > be known by the requester.
> >
> > The PIDFD_INFO_LANDLOCK_LAST_DOMAIN flag enables user space to get the
> > latest (i.e. most nested) Landlock domain ID related to a sandboxed
> > task, if any. The domain ID is set in the pidfd_info's
> > landlock_last_domain field according to the related mask.
> >
> > The PIDFD_INFO_LANDLOCK_FIRST_DOMAIN flag enables user space to get the
> > closest (i.e. first hierarchy relative to the pidfd's credentials)
> > Landlock domain ID related to a sandboxed task, if any. The domain ID
> > is set in the pidfd_info's landlock_first_domain field according to the
> > related mask.
> >
> > It is only allowed to get information about a Landlock domain if the
> > task's domain that created the pidfd is a parent of the PID's domain.
> > Following the object-capability model, the pidfd's credentials are used
> > instead of the caller's credentials. This makes this command
> > idenmpotent wrt the referenced process's state.
> >
> > If Landlock is not supported or if access to this information is denied,
> > then the IOCTL does not set the PIDFD_INFO_LANDLOCK_*_DOMAIN flag in the
> > returned mask.
> >
> > If PIDFD_INFO_LANDLOCK_LAST_DOMAIN or PIDFD_INFO_LANDLOCK_FIRST_DOMAIN
> > is specified but the provided struct pidfd_info is not large enough to
> > contain the related field, then -EINVAL is returned.
> >
> > Cc: Christian Brauner <brauner@kernel.org>
> > Cc: Günther Noack <gnoack@google.com>
> > Cc: Luca Boccassi <luca.boccassi@gmail.com>
> > Cc: Praveen K Paladugu <prapal@linux.microsoft.com>
> > Closes: https://github.com/landlock-lsm/linux/issues/26
> > Signed-off-by: Mickaël Salaün <mic@digikod.net>
> > Link: https://lore.kernel.org/r/20250131163447.1140564-3-mic@digikod.net
> > ---
> > fs/pidfs.c | 24 ++++++++++++++++++++++--
> > include/uapi/linux/pidfd.h | 4 ++++
> > 2 files changed, 26 insertions(+), 2 deletions(-)
>
> While there are exceptions, mostly for legacy things, we try very hard
> to avoid having the kernel call directly into a specific LSM,
> preferring to use LSM interfaces, both so that all LSMs can benefit
> from the change and also so that we can avoid having a lot of very
> similar, but LSM-specific, calls in various parts in the kernel.
Making life easier for LSMs by sharing common code is a good thing, but
making life easier for all kernel components by sharing common code is
even better. The PIDFD_GET_INFO IOCTL was design to be very flexible,
and it follows the principle of "pay for what you request" thanks to the
"mask" bitfield.
Users specify a set of properties they want, and the kernel returns
these properties if they are supported and allowed. Each of this
property is well-specified and has a clear semantic. This patch series
implements two Landlock properties, each clearly identified and
independent.
One important difference between the current LSMs attributes and these
two new Landlock properties, is that the Landlock domain IDs are u64
values instead of strings. This makes the implementation quite forward
and it fits well with how PIDFD_GET_INFO currently works, so there is no
need for a new (PIDFD_GET_SECURITY) IOCTL handling complex data
structure composing a set of strings such as what is required for
current LSMs' attributes.
>
> There is an effort, albeit a slowly moving effort due to interrupts,
> to add LSM support via a PIDFS_GET_SECURITY API:
>
> https://lore.kernel.org/linux-security-module/CAHC9VhRV3KcNGRw6_c-97G6w=HKNuEQoUGrfKhsQdWywzDDnBQ@mail.gmail.com/
This effort is good, but it is a separate effort which is independent
from this patch series. This will be useful for LSMs (or hopefully
other parts of the kernel as well) that deal with string-based
attributes.
Even with a common hook and data structure, any LSM need to implement
their own attribute management. This patch series just makes a call to
the Landlock implementation the same way UID, cgroupid, and other
properties are retrieved. There is no need for a wrapper interface for
simple data types that are already handled by PIDFD_GET_INFO.
Simple property types should all be queryable with the PIDFD_GET_INFO
IOCTL (compared to a dedicated LSM's PIDFD_GET_SECURITY IOCTL), which
can batch queries, making it more efficient and easier to implement for
user space.
>
> I don't see any reason why we couldn't support Landlock's domain info
> as part of that, the lsm_ctx struct was created to support various
> different LSM contexts/attributes. You could either add multiple
> lsm_ctx array entries for Landlock, one for each of the domain IDs, or
> you could place all of the domain IDs in an expanded lsm_ctx.
> Remember the lsm_ctx->ctx field can hold binary blobs and/or you can
> expand past the end of lsm_ctx->ctx so long as lsm_ctx->{len,ctx_len}
> are set accordingly.
>
> If you want to work on the PIDFS_GET_SECURITY patch(set) as a means to
> add Landlock domain ID support, I think that would be great. Luca
> provided a basic skeleton in the link above, and I expect you would
> have no issue adding the missing LSM bits.
>
> --
> paul-moore.com
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN
2025-02-01 10:28 ` Mickaël Salaün
@ 2025-02-01 11:09 ` Christian Brauner
2025-02-01 23:48 ` Paul Moore
1 sibling, 0 replies; 9+ messages in thread
From: Christian Brauner @ 2025-02-01 11:09 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Paul Moore, Günther Noack, Charles Zaffery, Daniel Burgener,
Francis Laniel, James Morris, Jann Horn, Jeff Xu, Kees Cook,
Luca Boccassi, Mikhail Ivanov, Praveen K Paladugu, Robert Salvet,
Shervin Oloumi, Tyler Hicks, linux-kernel, linux-security-module
On Sat, Feb 01, 2025 at 11:28:28AM +0100, Mickaël Salaün wrote:
> On Fri, Jan 31, 2025 at 02:02:49PM -0500, Paul Moore wrote:
> > On Fri, Jan 31, 2025 at 11:43 AM Mickaël Salaün <mic@digikod.net> wrote:
> > >
> > > Because Landlock enables users to create nested sandboxes (i.e.
> > > domains), we might need to identify the domain with all restrictions
> > > (latest), or the domain we created (i.e. closest domain). Indeed,
> > > because any process can create its own domain, the latest domain may not
> > > be known by the requester.
> > >
> > > The PIDFD_INFO_LANDLOCK_LAST_DOMAIN flag enables user space to get the
> > > latest (i.e. most nested) Landlock domain ID related to a sandboxed
> > > task, if any. The domain ID is set in the pidfd_info's
> > > landlock_last_domain field according to the related mask.
> > >
> > > The PIDFD_INFO_LANDLOCK_FIRST_DOMAIN flag enables user space to get the
> > > closest (i.e. first hierarchy relative to the pidfd's credentials)
> > > Landlock domain ID related to a sandboxed task, if any. The domain ID
> > > is set in the pidfd_info's landlock_first_domain field according to the
> > > related mask.
> > >
> > > It is only allowed to get information about a Landlock domain if the
> > > task's domain that created the pidfd is a parent of the PID's domain.
> > > Following the object-capability model, the pidfd's credentials are used
> > > instead of the caller's credentials. This makes this command
> > > idenmpotent wrt the referenced process's state.
> > >
> > > If Landlock is not supported or if access to this information is denied,
> > > then the IOCTL does not set the PIDFD_INFO_LANDLOCK_*_DOMAIN flag in the
> > > returned mask.
> > >
> > > If PIDFD_INFO_LANDLOCK_LAST_DOMAIN or PIDFD_INFO_LANDLOCK_FIRST_DOMAIN
> > > is specified but the provided struct pidfd_info is not large enough to
> > > contain the related field, then -EINVAL is returned.
> > >
> > > Cc: Christian Brauner <brauner@kernel.org>
> > > Cc: Günther Noack <gnoack@google.com>
> > > Cc: Luca Boccassi <luca.boccassi@gmail.com>
> > > Cc: Praveen K Paladugu <prapal@linux.microsoft.com>
> > > Closes: https://github.com/landlock-lsm/linux/issues/26
> > > Signed-off-by: Mickaël Salaün <mic@digikod.net>
> > > Link: https://lore.kernel.org/r/20250131163447.1140564-3-mic@digikod.net
> > > ---
> > > fs/pidfs.c | 24 ++++++++++++++++++++++--
> > > include/uapi/linux/pidfd.h | 4 ++++
> > > 2 files changed, 26 insertions(+), 2 deletions(-)
> >
> > While there are exceptions, mostly for legacy things, we try very hard
> > to avoid having the kernel call directly into a specific LSM,
> > preferring to use LSM interfaces, both so that all LSMs can benefit
> > from the change and also so that we can avoid having a lot of very
> > similar, but LSM-specific, calls in various parts in the kernel.
>
> Making life easier for LSMs by sharing common code is a good thing, but
> making life easier for all kernel components by sharing common code is
> even better. The PIDFD_GET_INFO IOCTL was design to be very flexible,
> and it follows the principle of "pay for what you request" thanks to the
> "mask" bitfield.
>
> Users specify a set of properties they want, and the kernel returns
> these properties if they are supported and allowed. Each of this
> property is well-specified and has a clear semantic. This patch series
> implements two Landlock properties, each clearly identified and
> independent.
>
> One important difference between the current LSMs attributes and these
> two new Landlock properties, is that the Landlock domain IDs are u64
> values instead of strings. This makes the implementation quite forward
> and it fits well with how PIDFD_GET_INFO currently works, so there is no
> need for a new (PIDFD_GET_SECURITY) IOCTL handling complex data
> structure composing a set of strings such as what is required for
> current LSMs' attributes.
>
> >
> > There is an effort, albeit a slowly moving effort due to interrupts,
> > to add LSM support via a PIDFS_GET_SECURITY API:
> >
> > https://lore.kernel.org/linux-security-module/CAHC9VhRV3KcNGRw6_c-97G6w=HKNuEQoUGrfKhsQdWywzDDnBQ@mail.gmail.com/
>
> This effort is good, but it is a separate effort which is independent
> from this patch series. This will be useful for LSMs (or hopefully
> other parts of the kernel as well) that deal with string-based
> attributes.
>
> Even with a common hook and data structure, any LSM need to implement
> their own attribute management. This patch series just makes a call to
> the Landlock implementation the same way UID, cgroupid, and other
> properties are retrieved. There is no need for a wrapper interface for
> simple data types that are already handled by PIDFD_GET_INFO.
>
> Simple property types should all be queryable with the PIDFD_GET_INFO
> IOCTL (compared to a dedicated LSM's PIDFD_GET_SECURITY IOCTL), which
> can batch queries, making it more efficient and easier to implement for
> user space.
Hm, I agree with Paul here. I'd rather see a unified PIDFD_GET_SECURITY
ioctl rather than plumbing bits of some LSMs into PIDFD_GET_INFO
directly. You can design the PIDFD_GET_SECURITY in a way that you can
get properties such as the landlock ids without any string handling.
There must be other security properties that don't want to be strings.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN
2025-02-01 10:28 ` Mickaël Salaün
2025-02-01 11:09 ` Christian Brauner
@ 2025-02-01 23:48 ` Paul Moore
1 sibling, 0 replies; 9+ messages in thread
From: Paul Moore @ 2025-02-01 23:48 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Christian Brauner, Günther Noack, Charles Zaffery,
Daniel Burgener, Francis Laniel, James Morris, Jann Horn, Jeff Xu,
Kees Cook, Luca Boccassi, Mikhail Ivanov, Praveen K Paladugu,
Robert Salvet, Shervin Oloumi, Tyler Hicks, linux-kernel,
linux-security-module
On February 1, 2025 5:28:37 AM Mickaël Salaün <mic@digikod.net> wrote:
> On Fri, Jan 31, 2025 at 02:02:49PM -0500, Paul Moore wrote:
>> On Fri, Jan 31, 2025 at 11:43 AM Mickaël Salaün <mic@digikod.net> wrote:
>>>
>>> Because Landlock enables users to create nested sandboxes (i.e.
>>> domains), we might need to identify the domain with all restrictions
>>> (latest), or the domain we created (i.e. closest domain). Indeed,
>>> because any process can create its own domain, the latest domain may not
>>> be known by the requester.
>>>
>>> The PIDFD_INFO_LANDLOCK_LAST_DOMAIN flag enables user space to get the
>>> latest (i.e. most nested) Landlock domain ID related to a sandboxed
>>> task, if any. The domain ID is set in the pidfd_info's
>>> landlock_last_domain field according to the related mask.
>>>
>>> The PIDFD_INFO_LANDLOCK_FIRST_DOMAIN flag enables user space to get the
>>> closest (i.e. first hierarchy relative to the pidfd's credentials)
>>> Landlock domain ID related to a sandboxed task, if any. The domain ID
>>> is set in the pidfd_info's landlock_first_domain field according to the
>>> related mask.
>>>
>>> It is only allowed to get information about a Landlock domain if the
>>> task's domain that created the pidfd is a parent of the PID's domain.
>>> Following the object-capability model, the pidfd's credentials are used
>>> instead of the caller's credentials. This makes this command
>>> idenmpotent wrt the referenced process's state.
>>>
>>> If Landlock is not supported or if access to this information is denied,
>>> then the IOCTL does not set the PIDFD_INFO_LANDLOCK_*_DOMAIN flag in the
>>> returned mask.
>>>
>>> If PIDFD_INFO_LANDLOCK_LAST_DOMAIN or PIDFD_INFO_LANDLOCK_FIRST_DOMAIN
>>> is specified but the provided struct pidfd_info is not large enough to
>>> contain the related field, then -EINVAL is returned.
>>>
>>> Cc: Christian Brauner <brauner@kernel.org>
>>> Cc: Günther Noack <gnoack@google.com>
>>> Cc: Luca Boccassi <luca.boccassi@gmail.com>
>>> Cc: Praveen K Paladugu <prapal@linux.microsoft.com>
>>> Closes: https://github.com/landlock-lsm/linux/issues/26
>>> Signed-off-by: Mickaël Salaün <mic@digikod.net>
>>> Link: https://lore.kernel.org/r/20250131163447.1140564-3-mic@digikod.net
>>> ---
>>> fs/pidfs.c | 24 ++++++++++++++++++++++--
>>> include/uapi/linux/pidfd.h | 4 ++++
>>> 2 files changed, 26 insertions(+), 2 deletions(-)
>>
>> While there are exceptions, mostly for legacy things, we try very hard
>> to avoid having the kernel call directly into a specific LSM,
>> preferring to use LSM interfaces, both so that all LSMs can benefit
>> from the change and also so that we can avoid having a lot of very
>> similar, but LSM-specific, calls in various parts in the kernel.
>
> Making life easier for LSMs by sharing common code is a good thing, but
> making life easier for all kernel components by sharing common code is
> even better. The PIDFD_GET_INFO IOCTL was design to be very flexible,
> and it follows the principle of "pay for what you request" thanks to the
> "mask" bitfield.
>
> Users specify a set of properties they want, and the kernel returns
> these properties if they are supported and allowed. Each of this
> property is well-specified and has a clear semantic. This patch series
> implements two Landlock properties, each clearly identified and
> independent.
>
> One important difference between the current LSMs attributes and these
> two new Landlock properties, is that the Landlock domain IDs are u64
> values instead of strings. This makes the implementation quite forward
> and it fits well with how PIDFD_GET_INFO currently works, so there is no
> need for a new (PIDFD_GET_SECURITY) IOCTL handling complex data
> structure composing a set of strings such as what is required for
> current LSMs' attributes.
Landlock is a LSM. Landlock properties *are* LSM properties/attributes,
regardless of data types. Look at a lot of the recent work to support
arbitrary types in the LSM syscalls as well the very recent work to start
moving away from the rigid secctx/secid concepts within the kernel.
Landlock is a LSM and just as all the other LSMs integrate with other areas
of the kernel through the LSM framework, so should Landlock. Instead of
adding landlock_* calls in the kernel, you need to adding security_* calls,
or better yet, finding ways to work with existing security_* calls.
>>
>> There is an effort, albeit a slowly moving effort due to interrupts,
>> to add LSM support via a PIDFS_GET_SECURITY API:
>>
>> https://lore.kernel.org/linux-security-module/CAHC9VhRV3KcNGRw6_c-97G6w=HKNuEQoUGrfKhsQdWywzDDnBQ@mail.gmail.com/
>
> This effort is good, but it is a separate effort which is independent
> from this patch series. This will be useful for LSMs (or hopefully
> other parts of the kernel as well) that deal with string-based
> attributes.
>
> Even with a common hook and data structure, any LSM need to implement
> their own attribute management. This patch series just makes a call to
> the Landlock implementation the same way UID, cgroupid, and other
> properties are retrieved. There is no need for a wrapper interface for
> simple data types that are already handled by PIDFD_GET_INFO.
>
> Simple property types should all be queryable with the PIDFD_GET_INFO
> IOCTL (compared to a dedicated LSM's PIDFD_GET_SECURITY IOCTL), which
> can batch queries, making it more efficient and easier to implement for
> user space.
I don't disagree that including LSM info in the existing PID_GET_INFO API
would be preferable, see my request at the 2024 LPC session on this as well
as some discussions with Luca, but you will see that Christian has blocked
this idea and forced us into a LSM specific API. It's not ideal in my
opinion, but it is better than nothing or having to do our solution in the
LSM space.
>
>>
>> I don't see any reason why we couldn't support Landlock's domain info
>> as part of that, the lsm_ctx struct was created to support various
>> different LSM contexts/attributes. You could either add multiple
>> lsm_ctx array entries for Landlock, one for each of the domain IDs, or
>> you could place all of the domain IDs in an expanded lsm_ctx.
>> Remember the lsm_ctx->ctx field can hold binary blobs and/or you can
>> expand past the end of lsm_ctx->ctx so long as lsm_ctx->{len,ctx_len}
>> are set accordingly.
>>
>> If you want to work on the PIDFS_GET_SECURITY patch(set) as a means to
>> add Landlock domain ID support, I think that would be great. Luca
>> provided a basic skeleton in the link above, and I expect you would
>> have no issue adding the missing LSM bits.
--
paul-moore.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFC PATCH v1 3/3] samples/landlock: Print domain ID
2025-01-31 16:34 [RFC PATCH v1 0/3] Expose Landlock domain IDs via pidfd Mickaël Salaün
2025-01-31 16:34 ` [RFC PATCH v1 1/3] landlock: Add landlock_read_domain_id() Mickaël Salaün
2025-01-31 16:34 ` [RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN Mickaël Salaün
@ 2025-01-31 16:34 ` Mickaël Salaün
2025-01-31 17:35 ` [RFC PATCH v1 0/3] Expose Landlock domain IDs via pidfd Mickaël Salaün
3 siblings, 0 replies; 9+ messages in thread
From: Mickaël Salaün @ 2025-01-31 16:34 UTC (permalink / raw)
To: Christian Brauner, Günther Noack
Cc: Mickaël Salaün, Charles Zaffery, Daniel Burgener,
Francis Laniel, James Morris, Jann Horn, Jeff Xu, Kees Cook,
Luca Boccassi, Mikhail Ivanov, Praveen K Paladugu, Robert Salvet,
Shervin Oloumi, Tyler Hicks, linux-kernel, linux-security-module
If the PIDFD_GET_INFO IOCTL command and the related
PIDFD_INFO_LANDLOCK_FIRST_DOMAIN flag are supported, print the newly
created domain before launching the sandboxed program.
Cc: Günther Noack <gnoack@google.com>
Cc: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20250131163447.1140564-4-mic@digikod.net
---
samples/landlock/sandboxer.c | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/samples/landlock/sandboxer.c b/samples/landlock/sandboxer.c
index 68a5f16bacd5..018bafaa470a 100644
--- a/samples/landlock/sandboxer.c
+++ b/samples/landlock/sandboxer.c
@@ -15,15 +15,20 @@
#include <linux/landlock.h>
#include <linux/prctl.h>
#include <linux/socket.h>
+#include <stdbool.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
+#include <sys/ioctl.h>
#include <sys/prctl.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <unistd.h>
-#include <stdbool.h>
+
+/* Avoids conflict with fcntl.h */
+#define _LINUX_FCNTL_H
+#include <linux/pidfd.h>
#ifndef landlock_create_ruleset
static inline int
@@ -53,6 +58,11 @@ static inline int landlock_restrict_self(const int ruleset_fd,
}
#endif
+static inline int sys_pidfd_open(const pid_t pid, const unsigned int flags)
+{
+ return syscall(__NR_pidfd_open, pid, flags);
+}
+
#define ENV_FS_RO_NAME "LL_FS_RO"
#define ENV_FS_RW_NAME "LL_FS_RW"
#define ENV_TCP_BIND_NAME "LL_TCP_BIND"
@@ -343,7 +353,7 @@ int main(const int argc, char *const argv[], char *const *const envp)
{
const char *cmd_path;
char *const *cmd_argv;
- int ruleset_fd, abi;
+ int ruleset_fd, abi, pidfd;
char *env_port_name, *env_force_log;
__u64 access_fs_ro = ACCESS_FS_ROUGHLY_READ,
access_fs_rw = ACCESS_FS_ROUGHLY_READ | ACCESS_FS_ROUGHLY_WRITE;
@@ -510,6 +520,9 @@ int main(const int argc, char *const argv[], char *const *const envp)
goto err_close_ruleset;
}
+ /* Opens our own pidfd before sandboxing, if supported. */
+ pidfd = sys_pidfd_open(getpid(), 0);
+
if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
perror("Failed to restrict privileges");
goto err_close_ruleset;
@@ -520,6 +533,18 @@ int main(const int argc, char *const argv[], char *const *const envp)
}
close(ruleset_fd);
+ if (pidfd >= 0) {
+ struct pidfd_info info = {
+ .mask = PIDFD_INFO_LANDLOCK_FIRST_DOMAIN,
+ };
+
+ if (!ioctl(pidfd, PIDFD_GET_INFO, &info) &&
+ (info.mask & PIDFD_INFO_LANDLOCK_FIRST_DOMAIN)) {
+ fprintf(stderr, "Entered the Landlock domain %llx.\n",
+ info.landlock_first_domain);
+ }
+ }
+
cmd_path = argv[1];
cmd_argv = argv + 1;
fprintf(stderr, "Executing the sandboxed command...\n");
--
2.48.1
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [RFC PATCH v1 0/3] Expose Landlock domain IDs via pidfd
2025-01-31 16:34 [RFC PATCH v1 0/3] Expose Landlock domain IDs via pidfd Mickaël Salaün
` (2 preceding siblings ...)
2025-01-31 16:34 ` [RFC PATCH v1 3/3] samples/landlock: Print domain ID Mickaël Salaün
@ 2025-01-31 17:35 ` Mickaël Salaün
3 siblings, 0 replies; 9+ messages in thread
From: Mickaël Salaün @ 2025-01-31 17:35 UTC (permalink / raw)
To: Christian Brauner, Günther Noack
Cc: Charles Zaffery, Daniel Burgener, Francis Laniel, James Morris,
Jann Horn, Jeff Xu, Kees Cook, Luca Boccassi, Mikhail Ivanov,
Praveen K Paladugu, Robert Salvet, Shervin Oloumi, Tyler Hicks,
linux-kernel, linux-security-module, linux-fsdevel, containers
On Fri, Jan 31, 2025 at 05:34:44PM +0100, Mickaël Salaün wrote:
> Hi,
>
> Landlock enables users to create unprivileged nested security sandboxes
> (i.e. domains). Each of these domains get a unique ID, which is used to
> identify and compare different domains. With the audit support, these
> IDs will be used in logs, but users also need a way to map these IDs to
> processes and directly read domain IDs of arbitrary tasks.
>
> pidfd is a reference to a task that enables users to interact with it
> and read some of its properties with the PIDFD_GET_INFO IOCTL. This
> patch series extend this interface with two new properties:
> PIDFD_INFO_LANDLOCK_LAST_DOMAIN and PIDFD_INFO_LANDLOCK_FIRST_DOMAIN.
>
> Being able to read tasks' domain IDs is useful for telemetry, debugging, and
> tests. It enables users:
> - to know if a task is well sandboxed;
> - to know which tasks are part of the same sandbox;
> - to map Landlock audit logs to running processes.
>
> Furthermore, thanks to recvmsg(2)'s SCM_PIDFD, it is also possible to reliably
> identify a peer's sandbox.
>
> This patch series is based on the audit support patch series v5:
> https://lore.kernel.org/all/20250108154338.1129069-1-mic@digikod.net/
That was the v4, here is the v5:
https://lore.kernel.org/all/20250131163059.1139617-1-mic@digikod.net/
>
> I'll talk about this feature at FOSDEM:
> https://fosdem.org/2025/schedule/event/fosdem-2025-6071-sandbox-ids-with-landlock/
>
> Regards,
>
> Mickaël Salaün (3):
> landlock: Add landlock_read_domain_id()
> pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN
> samples/landlock: Print domain ID
>
> fs/pidfs.c | 24 +++++++++++-
> include/linux/landlock.h | 26 +++++++++++++
> include/uapi/linux/pidfd.h | 4 ++
> samples/landlock/sandboxer.c | 29 +++++++++++++-
> security/landlock/Makefile | 12 ++++--
> security/landlock/domain.c | 2 -
> security/landlock/domain.h | 8 ++--
> security/landlock/ruleset.c | 2 +
> security/landlock/syscalls.c | 75 ++++++++++++++++++++++++++++++++++++
> 9 files changed, 169 insertions(+), 13 deletions(-)
> create mode 100644 include/linux/landlock.h
>
>
> base-commit: a4b76d5e6800121372b88c85628a7867a5fdc707
> --
> 2.48.1
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread