current landlock limitations and what it means for sandboxer

Hello, Mickaël

I would like to dig into the limitation of landlock, to understand
more about the design approach of using landlock for sandboxing user
space applications.

To give a context, assume this sandboxer will implement 3 categories
of access using landlock: RO/RW/RX for the file system.

Limitation 1> It is currently not possible to restrict some file-related
actions accessible through these syscall families: chdir(2),
truncate(2), stat(2), flock(2), chmod(2), chown(2), setxattr(2),
utime(2), ioctl(2), fcntl(2), access(2). Future Landlock evolutions
will enable them to restrict them.

Question:
Does this mean: root or unprivileged users can use those APIs to break
out the normal  expectation of (RO/RX/RW) ?

For example:  we assign "RO" on fileA using landlock, can application
truncate(2) to shrink file size (thus change the content of file) ?

If that is the case, potentially, the sandboxer needs to consider
applying additional security mechanisms.

Or, if there is a plan to address those limitations in the short term,
then there is less to think about in sandboxer design.

Limitation 2> As for file renaming and linking, a sandboxed thread
cannot modify its filesystem topology, whether via mount(2) or
pivot_root(2). However, chroot(2) calls are not denied.

Question: Can chroot(2) be used to break out landlock policy then ?
.
Limitation 3> Access to regular files and directories can be
restricted by Landlock, according to the handled accesses of a
ruleset. However, files that do not come from a user-visible
filesystem (e.g. pipe, socket), but can still be accessed through
/proc/<pid>/fd/*, cannot currently be explicitly restricted.

Questions:
Is this a feature Gap compared with SELinux ?
Is there a plan to add the support for files under /proc ?
Is pipe/socket related to network access-control types in the roadmap ?

Limitation 4> Likewise, some special kernel file systems such as nsfs,
which can be accessed through /proc/<pid>/ns/*, cannot currently be
explicitly restricted. However, thanks to the ptrace restrictions,
access to such sensitive /proc files are automatically restricted
according to domain hierarchies. Future Landlock evolutions could
still explicitly restrict such paths with dedicated ruleset flags.

Question:
This seems to say /proc/<pid>/ns/* can be protected by having the
right value in YAMA config, right ?
And just for my curiosities:  Are there other file types under /proc/
that are not mentioned here (pipe/socket/ns), and need to be
considered during this sandboxer design ?

Question > This question is not about a limitation.
Landlock is designed for unprivileged user processes (this is great!)

How about using it for root (user with SYS_ADMIN cap),  Can root break
out of the Landlock policy in theory?


Thanks
Best Regards,
Jeff Xu