current landlock limitations and what it means for sandboxer

current landlock limitations and what it means for sandboxer

[Jeff Xu]

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

Re: current landlock limitations and what it means for sandboxer

[Mickaël Salaün]

On 31/08/2022 02:22, Jeff Xu wrote:
> Hello, Mickaël

Hello Jeff,

Thanks for these interesting questions.

> 
> 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) ?

The root user can be multiple things, most of the time it gets all Linux 
capabilities and can then do everything. The goal of Landlock is not to 
restrict what can already be restricted by dropping capabilities, but to 
complement these native Linux interfaces. For instance, if a user is 
allowed to load arbitrary kernel code (e.g. with CAP_SYS_MODULE), then 
this user should be considered as totally unrestricted because it can 
tamper the kernel, and we first need to start with basic security 
configurations. That being said, a process running as root will get the 
same restrictions as any other user.


> 
> 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.

The currently non-restrictable syscall families are not blocked by 
Landlock and will be allowed to do what they do if all enabled 
access-control layers allow such access (i.e. DAC, capabilites, MAC). 
Making Landlock aware of all access types is a lot of effort and will 
take time: kernel code, user space updates, exhaustive tests, fuzzing, 
documentation, reviews…

About truncate(2), currently any landlocked thread can call it and if 
DAC/capabilities/MAC allow this action, it will be allowed. 
LANDLOCK_ACCESS_FS_WRITE_FILE only enables to restrict file opening with 
write access, but the truncate access is handled differently by the 
kernel: it is treated as a metadata modification (i.e. file attribute). 
A new LANDLOCK_ACCESS_FS_TRUNCATE right will enable to restrict the 
truncate syscall family with Linux 6.1 though: 
https://lore.kernel.org/r/20220817203006.21769-1-gnoack3000@gmail.com

In the meantime, using seccomp to filter the unhandled syscalls is a 
good approach, even if there are drawbacks: 
https://blog.gnoack.org/post/pledge-on-linux/


> 
> 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 ?

No, chroot(2) cannot be used to bypass Landlock. chroot is not denied 
because it doesn't modify the filesystem topology (but only the view of 
the root), and it can be used to further restrict sandboxed processes. 
It should be noted that processes allowed to chroot can escape a chroot, 
but as with chdir(2), it is unrelated to the Landlock access control.


> .
> 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 ?

/proc/<pid>/ are implicitly restricted by Landlock. Indeed, sandboxed 
processes cannot access resources (e.g. opened file descriptors, 
memory…) from processes pertaining to parent or sibling domains (a 
sandbox may be seen as a stack of domains). This domain scoping is 
required to forbid process/domain impersonation that could result in 
privilege escalation.

Some special files from /proc/<pid>/ may not be explicitly restricted by 
Landlock, but it should not be an issue. Please let me know if you have 
a use case that requires to restrict them more than they already are.

SELinux implicitly labels such files (e.g. FD pseudo symlinks) with the 
process's domain. The access restrictions are then pretty similar to 
what Landlock does, except that there is no way with Landlock to bypass 
such domain scoped restrictions.


> Is pipe/socket related to network access-control types in the roadmap ?

Named pipes and named sockets can be restricted by all Landlock versions 
though. I'm not sure it would be useful to add more restrictions to the 
/proc/<pid>/fd/* (special) symlinks because a process can only access 
the underlying files if it is in the same domain or a parent one.

FYI, there is also an ongoing effort to handle TCP sockets: 
https://lore.kernel.org/linux-security-module/20220829170401.834298-1-konstantin.meskhidze@huawei.com/


> 
> 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 ?

This is unrelated to Yama, but quite similar. Instead of relying on 
process hierarchy like Yama can do, Landlock relies on domain 
hierarchies. A Landlock domain cannot access sensitive /proc/* files 
from outside its domain or its child domains.


> 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 ?

There are other files but all sensitive files should be handled by 
Landlock (and other kernel subsystems). See 
kernel/ptrace.c:ptrace_may_access() calls. You can easily check that 
with the sandboxer tool.

BTW, /proc can be mounted with "hidepid=2", which makes invisible the 
directories of all processes not in the domain's scope.


> 
> 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?

Any user with powerful capabilities such as CAP_SYS_ADMIN are 
legitimately allowed to bypass most Linux access controls. Landlock 
always denies some actions (e.g. mounts) to sandboxed processes, but 
powerful capabilities could be leveraged to bypass such restrictions. 
Processes with such capabilities are not part of the current Landlock 
threat model. However, using Landlock in this case could still be 
interesting from a safety point of view.

For instance, the (sandboxed) root user may be allowed to create a new 
service that may be launched by a non-sandboxed process, which could 
then do whatever the root user wants. Sandboxing a user that 
legitimately needs such power seems inappropriate, and we cannot really 
answer such question without a specific context.

Linux has multiple ways to restrict processes (e.g drop capabilities) 
and Landlock is only filling an (important) gap in this set of features. 
Anyway, most Linux capabilities are too coarse and their use should be 
replaced with the use of tailored brokers. Some examples: 
https://forums.grsecurity.net/viewtopic.php?f=7&t=2522

Regards,
  Mickaël

> 
> 
> Thanks
> Best Regards,
> Jeff Xu

Re: current landlock limitations and what it means for sandboxer

[Jay Freyensee]

On 8/31/22 6:31 AM, Mickaël Salaün wrote:
>
> On 31/08/2022 02:22, Jeff Xu wrote:
>> Hello, Mickaël
>
> Hello Jeff,
>
> Thanks for these interesting questions.
>
>>
>> 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.


This has spurred a long standing curiosity with meon landlock.  Can 
landlock quarrantine a bad-acting binary discovered during machine 
operation?  The way I've understood landlock is it can be used to 
restrict a set of unprivileged processes to sandboxes known on say, 
machine boot up.   But what if during normal operation an anti-malware 
program flags a suspect binary running on a system, but it isn't 100% 
sure that binary is malicious?  Could landlock "lock away" and sandbox 
the suspect-binary for analysis by an admin to determine that suspect 
binary is in fact malicious and should be deleted from the system?  And 
if the suspect binary is determined to be harmless can it be 
unsandboxed/put-back?


Thanks,

Jay

Re: current landlock limitations and what it means for sandboxer

[Mickaël Salaün]

On 31/08/2022 17:48, Jay Freyensee wrote:
> 
> On 8/31/22 6:31 AM, Mickaël Salaün wrote:
>>
>> On 31/08/2022 02:22, Jeff Xu wrote:
>>> Hello, Mickaël
>>
>> Hello Jeff,
>>
>> Thanks for these interesting questions.
>>
>>>
>>> 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.
> 
> 
> This has spurred a long standing curiosity with meon landlock.  Can
> landlock quarrantine a bad-acting binary discovered during machine
> operation?  The way I've understood landlock is it can be used to
> restrict a set of unprivileged processes to sandboxes known on say,
> machine boot up.   But what if during normal operation an anti-malware
> program flags a suspect binary running on a system, but it isn't 100%
> sure that binary is malicious?  Could landlock "lock away" and sandbox
> the suspect-binary for analysis by an admin to determine that suspect
> binary is in fact malicious and should be deleted from the system?  And
> if the suspect binary is determined to be harmless can it be
> unsandboxed/put-back?

For now, a process can only sandbox itself, the same way seccomp works. 
Such process is then stuck in the sandbox for its whole lifetime.

I think, being able to dynamically move a process in or out of a 
(dedicated) sandbox could be implemented leveraging cgroups, but there 
is some challenge to make it efficient.

fanotify(7) might be interesting for this anti-malware case though.