<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/security/landlock, branch linux-6.8.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>landlock: Warn once if a Landlock action is requested while disabled</title>
<updated>2024-04-03T13:32:15+00:00</updated>
<author>
<name>Mickaël Salaün</name>
<email>mic@digikod.net</email>
</author>
<published>2024-02-27T11:05:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6afa86eb39ef6181c3a3cb8fb1206b4707e0f02e'/>
<id>6afa86eb39ef6181c3a3cb8fb1206b4707e0f02e</id>
<content type='text'>
[ Upstream commit 782191c74875cc33b50263e21d76080b1411884d ]

Because sandboxing can be used as an opportunistic security measure,
user space may not log unsupported features.  Let the system
administrator know if an application tries to use Landlock but failed
because it isn't enabled at boot time.  This may be caused by boot
loader configurations with outdated "lsm" kernel's command-line
parameter.

Cc: stable@vger.kernel.org
Fixes: 265885daf3e5 ("landlock: Add syscall implementations")
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Günther Noack &lt;gnoack3000@gmail.com&gt;
Link: https://lore.kernel.org/r/20240227110550.3702236-2-mic@digikod.net
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 782191c74875cc33b50263e21d76080b1411884d ]

Because sandboxing can be used as an opportunistic security measure,
user space may not log unsupported features.  Let the system
administrator know if an application tries to use Landlock but failed
because it isn't enabled at boot time.  This may be caused by boot
loader configurations with outdated "lsm" kernel's command-line
parameter.

Cc: stable@vger.kernel.org
Fixes: 265885daf3e5 ("landlock: Add syscall implementations")
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Günther Noack &lt;gnoack3000@gmail.com&gt;
Link: https://lore.kernel.org/r/20240227110550.3702236-2-mic@digikod.net
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>landlock: Fix asymmetric private inodes referring</title>
<updated>2024-02-26T17:23:53+00:00</updated>
<author>
<name>Mickaël Salaün</name>
<email>mic@digikod.net</email>
</author>
<published>2024-02-19T19:03:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d9818b3e906a0ee1ab02ea79e74a2f755fc5461a'/>
<id>d9818b3e906a0ee1ab02ea79e74a2f755fc5461a</id>
<content type='text'>
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 &lt;arnd@arndb.de&gt;
Cc: Christian Brauner &lt;brauner@kernel.org&gt;
Cc: Günther Noack &lt;gnoack@google.com&gt;
Cc: Jann Horn &lt;jannh@google.com&gt;
Cc: Shervin Oloumi &lt;enlightened@chromium.org&gt;
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 &lt;mic@digikod.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;arnd@arndb.de&gt;
Cc: Christian Brauner &lt;brauner@kernel.org&gt;
Cc: Günther Noack &lt;gnoack@google.com&gt;
Cc: Jann Horn &lt;jannh@google.com&gt;
Cc: Shervin Oloumi &lt;enlightened@chromium.org&gt;
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 &lt;mic@digikod.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'landlock-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux</title>
<updated>2024-01-09T21:22:15+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-01-09T21:22:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e9b4c5890858015bfe2089b7573319bcf4a92907'/>
<id>e9b4c5890858015bfe2089b7573319bcf4a92907</id>
<content type='text'>
Pull Landlock updates from Mickaël Salaün:
 "New tests, a slight optimization, and some cosmetic changes"

* tag 'landlock-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux:
  landlock: Optimize the number of calls to get_access_mask slightly
  selftests/landlock: Rename "permitted" to "allowed" in ftruncate tests
  landlock: Remove remaining "inline" modifiers in .c files [v6.6]
  landlock: Remove remaining "inline" modifiers in .c files [v6.1]
  landlock: Remove remaining "inline" modifiers in .c files [v5.15]
  selftests/landlock: Add tests to check unhandled rule's access rights
  selftests/landlock: Add tests to check unknown rule's access rights
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull Landlock updates from Mickaël Salaün:
 "New tests, a slight optimization, and some cosmetic changes"

* tag 'landlock-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux:
  landlock: Optimize the number of calls to get_access_mask slightly
  selftests/landlock: Rename "permitted" to "allowed" in ftruncate tests
  landlock: Remove remaining "inline" modifiers in .c files [v6.6]
  landlock: Remove remaining "inline" modifiers in .c files [v6.1]
  landlock: Remove remaining "inline" modifiers in .c files [v5.15]
  selftests/landlock: Add tests to check unhandled rule's access rights
  selftests/landlock: Add tests to check unknown rule's access rights
</pre>
</div>
</content>
</entry>
<entry>
<title>landlock: Optimize the number of calls to get_access_mask slightly</title>
<updated>2024-01-03T11:43:17+00:00</updated>
<author>
<name>Günther Noack</name>
<email>gnoack@google.com</email>
</author>
<published>2023-12-08T15:51:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0daaa610c8e033cdfb420db728c2b40eb3a75134'/>
<id>0daaa610c8e033cdfb420db728c2b40eb3a75134</id>
<content type='text'>
This call is now going through a function pointer,
and it is not as obvious any more that it will be inlined.

Signed-off-by: Günther Noack &lt;gnoack@google.com&gt;
Link: https://lore.kernel.org/r/20231208155121.1943775-4-gnoack@google.com
Fixes: 7a11275c3787 ("landlock: Refactor layer helpers")
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This call is now going through a function pointer,
and it is not as obvious any more that it will be inlined.

Signed-off-by: Günther Noack &lt;gnoack@google.com&gt;
Link: https://lore.kernel.org/r/20231208155121.1943775-4-gnoack@google.com
Fixes: 7a11275c3787 ("landlock: Refactor layer helpers")
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>landlock: Remove remaining "inline" modifiers in .c files [v6.6]</title>
<updated>2024-01-03T11:07:57+00:00</updated>
<author>
<name>Günther Noack</name>
<email>gnoack@google.com</email>
</author>
<published>2023-12-08T15:51:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3406ebade1a84d1cdb0c342e1506b97a579d3834'/>
<id>3406ebade1a84d1cdb0c342e1506b97a579d3834</id>
<content type='text'>
For module-internal static functions, compilers are already in a good
position to decide whether to inline them or not.

Suggested-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Günther Noack &lt;gnoack@google.com&gt;
Link: https://lore.kernel.org/r/20231208155121.1943775-2-gnoack@google.com
[mic: Split patch for Linux 6.6]
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For module-internal static functions, compilers are already in a good
position to decide whether to inline them or not.

Suggested-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Günther Noack &lt;gnoack@google.com&gt;
Link: https://lore.kernel.org/r/20231208155121.1943775-2-gnoack@google.com
[mic: Split patch for Linux 6.6]
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>landlock: Remove remaining "inline" modifiers in .c files [v6.1]</title>
<updated>2024-01-03T11:07:56+00:00</updated>
<author>
<name>Günther Noack</name>
<email>gnoack@google.com</email>
</author>
<published>2023-12-08T15:51:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=da279087b9d9f288609380baf2b6bb89874769d7'/>
<id>da279087b9d9f288609380baf2b6bb89874769d7</id>
<content type='text'>
For module-internal static functions, compilers are already in a good
position to decide whether to inline them or not.

Suggested-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Günther Noack &lt;gnoack@google.com&gt;
Link: https://lore.kernel.org/r/20231208155121.1943775-2-gnoack@google.com
[mic: Split patch for Linux 6.1]
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For module-internal static functions, compilers are already in a good
position to decide whether to inline them or not.

Suggested-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Günther Noack &lt;gnoack@google.com&gt;
Link: https://lore.kernel.org/r/20231208155121.1943775-2-gnoack@google.com
[mic: Split patch for Linux 6.1]
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>landlock: Remove remaining "inline" modifiers in .c files [v5.15]</title>
<updated>2024-01-03T11:07:52+00:00</updated>
<author>
<name>Günther Noack</name>
<email>gnoack@google.com</email>
</author>
<published>2023-12-08T15:51:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8fd80721ec0791826a9ab56656d26931811702f8'/>
<id>8fd80721ec0791826a9ab56656d26931811702f8</id>
<content type='text'>
For module-internal static functions, compilers are already in a good
position to decide whether to inline them or not.

Suggested-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Günther Noack &lt;gnoack@google.com&gt;
Link: https://lore.kernel.org/r/20231208155121.1943775-2-gnoack@google.com
[mic: Split patch for Linux 5.15]
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For module-internal static functions, compilers are already in a good
position to decide whether to inline them or not.

Suggested-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Günther Noack &lt;gnoack@google.com&gt;
Link: https://lore.kernel.org/r/20231208155121.1943775-2-gnoack@google.com
[mic: Split patch for Linux 5.15]
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>LSM: Identify modules by more than name</title>
<updated>2023-11-13T03:54:42+00:00</updated>
<author>
<name>Casey Schaufler</name>
<email>casey@schaufler-ca.com</email>
</author>
<published>2023-09-12T20:56:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f3b8788cde61b02f1e6c202f8fac4360e6adbafc'/>
<id>f3b8788cde61b02f1e6c202f8fac4360e6adbafc</id>
<content type='text'>
Create a struct lsm_id to contain identifying information about Linux
Security Modules (LSMs). At inception this contains the name of the
module and an identifier associated with the security module.  Change
the security_add_hooks() interface to use this structure.  Change the
individual modules to maintain their own struct lsm_id and pass it to
security_add_hooks().

The values are for LSM identifiers are defined in a new UAPI
header file linux/lsm.h. Each existing LSM has been updated to
include it's LSMID in the lsm_id.

The LSM ID values are sequential, with the oldest module
LSM_ID_CAPABILITY being the lowest value and the existing modules
numbered in the order they were included in the main line kernel.
This is an arbitrary convention for assigning the values, but
none better presents itself. The value 0 is defined as being invalid.
The values 1-99 are reserved for any special case uses which may
arise in the future. This may include attributes of the LSM
infrastructure itself, possibly related to namespacing or network
attribute management. A special range is identified for such attributes
to help reduce confusion for developers unfamiliar with LSMs.

LSM attribute values are defined for the attributes presented by
modules that are available today. As with the LSM IDs, The value 0
is defined as being invalid. The values 1-99 are reserved for any
special case uses which may arise in the future.

Cc: linux-security-module &lt;linux-security-module@vger.kernel.org&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Serge Hallyn &lt;serge@hallyn.com&gt;
Reviewed-by: Mickael Salaun &lt;mic@digikod.net&gt;
Reviewed-by: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Nacked-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
[PM: forward ported beyond v6.6 due merge window changes]
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Create a struct lsm_id to contain identifying information about Linux
Security Modules (LSMs). At inception this contains the name of the
module and an identifier associated with the security module.  Change
the security_add_hooks() interface to use this structure.  Change the
individual modules to maintain their own struct lsm_id and pass it to
security_add_hooks().

The values are for LSM identifiers are defined in a new UAPI
header file linux/lsm.h. Each existing LSM has been updated to
include it's LSMID in the lsm_id.

The LSM ID values are sequential, with the oldest module
LSM_ID_CAPABILITY being the lowest value and the existing modules
numbered in the order they were included in the main line kernel.
This is an arbitrary convention for assigning the values, but
none better presents itself. The value 0 is defined as being invalid.
The values 1-99 are reserved for any special case uses which may
arise in the future. This may include attributes of the LSM
infrastructure itself, possibly related to namespacing or network
attribute management. A special range is identified for such attributes
to help reduce confusion for developers unfamiliar with LSMs.

LSM attribute values are defined for the attributes presented by
modules that are available today. As with the LSM IDs, The value 0
is defined as being invalid. The values 1-99 are reserved for any
special case uses which may arise in the future.

Cc: linux-security-module &lt;linux-security-module@vger.kernel.org&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Serge Hallyn &lt;serge@hallyn.com&gt;
Reviewed-by: Mickael Salaun &lt;mic@digikod.net&gt;
Reviewed-by: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Nacked-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
[PM: forward ported beyond v6.6 due merge window changes]
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>landlock: Support network rules with TCP bind and connect</title>
<updated>2023-10-26T19:07:15+00:00</updated>
<author>
<name>Konstantin Meskhidze</name>
<email>konstantin.meskhidze@huawei.com</email>
</author>
<published>2023-10-26T01:47:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fff69fb03dde1dfa348cfdb74b13287dabe42c25'/>
<id>fff69fb03dde1dfa348cfdb74b13287dabe42c25</id>
<content type='text'>
Add network rules support in the ruleset management helpers and the
landlock_create_ruleset() syscall. Extend user space API to support
network actions:
* Add new network access rights: LANDLOCK_ACCESS_NET_BIND_TCP and
  LANDLOCK_ACCESS_NET_CONNECT_TCP.
* Add a new network rule type: LANDLOCK_RULE_NET_PORT tied to struct
  landlock_net_port_attr. The allowed_access field contains the network
  access rights, and the port field contains the port value according to
  the controlled protocol. This field can take up to a 64-bit value
  but the maximum value depends on the related protocol (e.g. 16-bit
  value for TCP). Network port is in host endianness [1].
* Add a new handled_access_net field to struct landlock_ruleset_attr
  that contains network access rights.
* Increment the Landlock ABI version to 4.

Implement socket_bind() and socket_connect() LSM hooks, which enable
to control TCP socket binding and connection to specific ports.

Expand access_masks_t from u16 to u32 to be able to store network access
rights alongside filesystem access rights for rulesets' handled access
rights.

Access rights are not tied to socket file descriptors but checked at
bind() or connect() call time against the caller's Landlock domain. For
the filesystem, a file descriptor is a direct access to a file/data.
However, for network sockets, we cannot identify for which data or peer
a newly created socket will give access to. Indeed, we need to wait for
a connect or bind request to identify the use case for this socket.
Likewise a directory file descriptor may enable to open another file
(i.e. a new data item), but this opening is also restricted by the
caller's domain, not the file descriptor's access rights [2].

[1] https://lore.kernel.org/r/278ab07f-7583-a4e0-3d37-1bacd091531d@digikod.net
[2] https://lore.kernel.org/r/263c1eb3-602f-57fe-8450-3f138581bee7@digikod.net

Signed-off-by: Konstantin Meskhidze &lt;konstantin.meskhidze@huawei.com&gt;
Link: https://lore.kernel.org/r/20231026014751.414649-9-konstantin.meskhidze@huawei.com
[mic: Extend commit message, fix typo in comments, and specify
endianness in the documentation]
Co-developed-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add network rules support in the ruleset management helpers and the
landlock_create_ruleset() syscall. Extend user space API to support
network actions:
* Add new network access rights: LANDLOCK_ACCESS_NET_BIND_TCP and
  LANDLOCK_ACCESS_NET_CONNECT_TCP.
* Add a new network rule type: LANDLOCK_RULE_NET_PORT tied to struct
  landlock_net_port_attr. The allowed_access field contains the network
  access rights, and the port field contains the port value according to
  the controlled protocol. This field can take up to a 64-bit value
  but the maximum value depends on the related protocol (e.g. 16-bit
  value for TCP). Network port is in host endianness [1].
* Add a new handled_access_net field to struct landlock_ruleset_attr
  that contains network access rights.
* Increment the Landlock ABI version to 4.

Implement socket_bind() and socket_connect() LSM hooks, which enable
to control TCP socket binding and connection to specific ports.

Expand access_masks_t from u16 to u32 to be able to store network access
rights alongside filesystem access rights for rulesets' handled access
rights.

Access rights are not tied to socket file descriptors but checked at
bind() or connect() call time against the caller's Landlock domain. For
the filesystem, a file descriptor is a direct access to a file/data.
However, for network sockets, we cannot identify for which data or peer
a newly created socket will give access to. Indeed, we need to wait for
a connect or bind request to identify the use case for this socket.
Likewise a directory file descriptor may enable to open another file
(i.e. a new data item), but this opening is also restricted by the
caller's domain, not the file descriptor's access rights [2].

[1] https://lore.kernel.org/r/278ab07f-7583-a4e0-3d37-1bacd091531d@digikod.net
[2] https://lore.kernel.org/r/263c1eb3-602f-57fe-8450-3f138581bee7@digikod.net

Signed-off-by: Konstantin Meskhidze &lt;konstantin.meskhidze@huawei.com&gt;
Link: https://lore.kernel.org/r/20231026014751.414649-9-konstantin.meskhidze@huawei.com
[mic: Extend commit message, fix typo in comments, and specify
endianness in the documentation]
Co-developed-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>landlock: Refactor landlock_add_rule() syscall</title>
<updated>2023-10-26T19:07:14+00:00</updated>
<author>
<name>Konstantin Meskhidze</name>
<email>konstantin.meskhidze@huawei.com</email>
</author>
<published>2023-10-26T01:47:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0e0fc7e8eb4a11bd9f89a9c74bc7c0e144c56203'/>
<id>0e0fc7e8eb4a11bd9f89a9c74bc7c0e144c56203</id>
<content type='text'>
Change the landlock_add_rule() syscall to support new rule types with
next commits. Add the add_rule_path_beneath() helper to support current
filesystem rules.

Signed-off-by: Konstantin Meskhidze &lt;konstantin.meskhidze@huawei.com&gt;
Link: https://lore.kernel.org/r/20231026014751.414649-8-konstantin.meskhidze@huawei.com
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change the landlock_add_rule() syscall to support new rule types with
next commits. Add the add_rule_path_beneath() helper to support current
filesystem rules.

Signed-off-by: Konstantin Meskhidze &lt;konstantin.meskhidze@huawei.com&gt;
Link: https://lore.kernel.org/r/20231026014751.414649-8-konstantin.meskhidze@huawei.com
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
