Landlock setup

Landlock setup

[Yves Rutschle]

Hello everyone,

Following Mickael's presentation of Landlock at
Pass-the-Salt 2022, I intend to add support for it to sslh.

I'm starting from the beginning: compiling and running the
example, which so far complains the LSM is not loaded, when
the kernel tells me it is...

I'm running a stock Debian where I manually add landlock to
the command line:

[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.18.0-3-amd64 root=UUID=79c3bdf6-4be2-46d6-b006-bb17170247b1 ro quiet lsm=landlock

the kernel indicates the LSM is started:

[    0.076550] LSM: Security Framework initializing
[    0.076559] landlock: Up and running.


Yet running the example fails:

# LL_FS_RO="/bin:/lib:/usr:/proc:/etc:/dev/urandom" LL_FS_RW="/dev/null:/dev/full:/dev/zero:/dev/pts:/tmp" ./lock bash -i
Failed to check Landlock compatibility: Function not implemented
Hint: Landlock is not supported by the current kernel. To support it, build the kernel with CONFIG_SECURITY_LANDLOCK=y and prepend "landlock," to the content of CONFIG_LSM.



What would I be doing wrong?

Cheers,
Y.

Re: Landlock setup

[Mickaël Salaün]

Hi Yves,

On 07/11/2022 18:22, Yves Rutschle wrote:
> Hello everyone,
> 
> Following Mickael's presentation of Landlock at
> Pass-the-Salt 2022, I intend to add support for it to sslh.
> 
> I'm starting from the beginning: compiling and running the
> example, which so far complains the LSM is not loaded, when
> the kernel tells me it is...
> 
> I'm running a stock Debian where I manually add landlock to
> the command line:
> 
> [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.18.0-3-amd64 root=UUID=79c3bdf6-4be2-46d6-b006-bb17170247b1 ro quiet lsm=landlock

This is correct, but you may also want to enable other LSMs if you are 
using them (e.g. Yama). You should probably stick to the new default 
Debian Sid cmdline: 
https://salsa.debian.org/kernel-team/linux/-/commit/1ef40f40e593a5dc223e9ce171fa8f2cd5aba198

> 
> the kernel indicates the LSM is started:
> 
> [    0.076550] LSM: Security Framework initializing
> [    0.076559] landlock: Up and running.
> 
> 
> Yet running the example fails:
> 
> # LL_FS_RO="/bin:/lib:/usr:/proc:/etc:/dev/urandom" LL_FS_RW="/dev/null:/dev/full:/dev/zero:/dev/pts:/tmp" ./lock bash -i
> Failed to check Landlock compatibility: Function not implemented
> Hint: Landlock is not supported by the current kernel. To support it, build the kernel with CONFIG_SECURITY_LANDLOCK=y and prepend "landlock," to the content of CONFIG_LSM.
> 
> 
> 
> What would I be doing wrong?

Your setup is good and it should work. You can debug a bit more with an 
up-to-date strace (which will print the Landlock syscalls). I guess you 
are running this sample in a strict seccomp environment that denies 
Landlock syscalls. This may be the result of using an old container 
runtime (Docker, Podman and runc are now patched but the related fix may 
not be backported).

Re: Landlock setup

[Yves Rutschle]

On Mon, Nov 07, 2022 at 07:02:04PM +0100, Mickaël Salaün wrote:
> This is correct, but you may also want to enable other LSMs if you are using
> them (e.g. Yama). You should probably stick to the new default Debian Sid
> cmdline: https://salsa.debian.org/kernel-team/linux/-/commit/1ef40f40e593a5dc223e9ce171fa8f2cd5aba198

I'm on Debian 11 on this PC, which enables... nothing.

> Your setup is good and it should work. You can debug a bit more with an
> up-to-date strace (which will print the Landlock syscalls). I guess you are
> running this sample in a strict seccomp environment that denies Landlock
> syscalls. This may be the result of using an old container runtime (Docker,
> Podman and runc are now patched but the related fix may not be backported).

strace:

[...]
mprotect(0x7f5189b04000, 16384, PROT_READ) = 0
mprotect(0x558557b7c000, 4096, PROT_READ) = 0
mprotect(0x7f5189b5c000, 8192, PROT_READ) = 0
munmap(0x7f5189b15000, 94575)           = 0
[ Process PID=3958 runs in x32 mode. ]
syscall_0x400001bc(0, 0, 0x1, 0, 0x7f5189b3d2b0, 0x40) = -1 ENOSYS (Function not implemented)
[ Process PID=3958 runs in 64 bit mode. ]
dup(2)                                  = 3
[...]

=> I guess strace is not up to date. I dont think I have
seccomp enabled either, and I think it would interrupt (as
in kill) the syscall rather than return ENOSYS. I am not
running from a docker either.


Ok, so I guess I'll look into upgrading the kernel and
strace, or compiling it myself.

Cheers,
Y.

Re: Landlock setup

[Mickaël Salaün]

On 08/11/2022 12:27, Yves Rutschle wrote:
> On Mon, Nov 07, 2022 at 07:02:04PM +0100, Mickaël Salaün wrote:
>> This is correct, but you may also want to enable other LSMs if you are using
>> them (e.g. Yama). You should probably stick to the new default Debian Sid
>> cmdline: https://salsa.debian.org/kernel-team/linux/-/commit/1ef40f40e593a5dc223e9ce171fa8f2cd5aba198
> 
> I'm on Debian 11 on this PC, which enables... nothing.

Right, but it doesn't hurt to stick to the future default. :)

> 
>> Your setup is good and it should work. You can debug a bit more with an
>> up-to-date strace (which will print the Landlock syscalls). I guess you are
>> running this sample in a strict seccomp environment that denies Landlock
>> syscalls. This may be the result of using an old container runtime (Docker,
>> Podman and runc are now patched but the related fix may not be backported).
> 
> strace:
> 
> [...]
> mprotect(0x7f5189b04000, 16384, PROT_READ) = 0
> mprotect(0x558557b7c000, 4096, PROT_READ) = 0
> mprotect(0x7f5189b5c000, 8192, PROT_READ) = 0
> munmap(0x7f5189b15000, 94575)           = 0
> [ Process PID=3958 runs in x32 mode. ]
> syscall_0x400001bc(0, 0, 0x1, 0, 0x7f5189b3d2b0, 0x40) = -1 ENOSYS (Function not implemented)
> [ Process PID=3958 runs in 64 bit mode. ]
> dup(2)                                  = 3
> [...]
> 
> => I guess strace is not up to date. I dont think I have
> seccomp enabled either, and I think it would interrupt (as
> in kill) the syscall rather than return ENOSYS. I am not
> running from a docker either.

If you see "landlock: Up and running." in the running kernel log, I 
don't see any reason why the kernel would return ENOSYS for the Landlock 
syscalls.

The default kernel for Debian 11 is Linux 5.10, which doesn't support 
Landlock. I tested with linux-image-5.18.0-0.deb11.4-amd64 and 
linux-image-6.0.0-0.deb11.2-amd64-unsigned and it works fine.

On which architecture are you?

> 
> 
> Ok, so I guess I'll look into upgrading the kernel and
> strace, or compiling it myself.

No need to update strace to debug this issue, it will just not print the 
syscall names and not format their arguments.

> 
> Cheers,
> Y.
> 

Re: Landlock setup

[Yves Rutschle]

On Tue, Nov 08, 2022 at 03:13:39PM +0100, Mickaël Salaün wrote:
> If you see "landlock: Up and running." in the running kernel log, I don't
> see any reason why the kernel would return ENOSYS for the Landlock syscalls.
> 
> The default kernel for Debian 11 is Linux 5.10, which doesn't support
> Landlock. I tested with linux-image-5.18.0-0.deb11.4-amd64 and
> linux-image-6.0.0-0.deb11.2-amd64-unsigned and it works fine.
> 
> On which architecture are you?

Ah, the mystery thickens, as I have a more recent version:

Package: linux-image-5.18.0-3-amd64
Version: 5.18.14-1

# uname -a
Linux hallertau 5.18.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.14-1 (2022-07-23) x86_64 GNU/Linux

My bad about the version, I guess I upgraded only the kernel
from Sid at some point.

Y.

Re: Landlock setup

[Mickaël Salaün]

Hi Yves,

How did your investigation to use Landlock go?


On 08/11/2022 18:15, Yves Rutschle wrote:
> On Tue, Nov 08, 2022 at 03:13:39PM +0100, Mickaël Salaün wrote:
>> If you see "landlock: Up and running." in the running kernel log, I don't
>> see any reason why the kernel would return ENOSYS for the Landlock syscalls.
>>
>> The default kernel for Debian 11 is Linux 5.10, which doesn't support
>> Landlock. I tested with linux-image-5.18.0-0.deb11.4-amd64 and
>> linux-image-6.0.0-0.deb11.2-amd64-unsigned and it works fine.
>>
>> On which architecture are you?
> 
> Ah, the mystery thickens, as I have a more recent version:
> 
> Package: linux-image-5.18.0-3-amd64
> Version: 5.18.14-1
> 
> # uname -a
> Linux hallertau 5.18.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.14-1 (2022-07-23) x86_64 GNU/Linux
> 
> My bad about the version, I guess I upgraded only the kernel
> from Sid at some point.
> 
> Y.
> 
> 

Re: Landlock setup

[Yves Rutschle]

Hi Mickaël,

On Fri, Dec 16, 2022 at 10:44:45AM +0100, Mickaël Salaün wrote:
> Hi Yves,
> 
> How did your investigation to use Landlock go?

I havent had time to dig much into it. Something I thought
might be a problem is that I retrieved landlock.h from your
git, and I wondered it might be different to what is
required to work with my stock kernel.

I'm hoping to find some time to look at this over the
holidays...


Cheers,
Y.

Re: Landlock setup

[Mickaël Salaün]

On 16/12/2022 10:53, Yves Rutschle wrote:
> Hi Mickaël,
> 
> On Fri, Dec 16, 2022 at 10:44:45AM +0100, Mickaël Salaün wrote:
>> Hi Yves,
>>
>> How did your investigation to use Landlock go?
> 
> I havent had time to dig much into it. Something I thought
> might be a problem is that I retrieved landlock.h from your
> git, and I wondered it might be different to what is
> required to work with my stock kernel.

You can get any Linux's mainline landlock.h [1] and update them from 
time to time, their API will be backward compatible. You can either use 
a standalone copy of this file or rely on libc's headers with a build 
configuration like AC_CHECK_HEADERS([linux/landlock.h]). See [2] for a 
full standalone example.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/landlock.h
[2] 
https://github.com/OISF/suricata/pull/7853/commits/485d5a4ea46dd90e228b3e4856b95a67a51d348c

Relying on a standalone copy has the advantage of to require a simpler 
code with less static check to make sure a specific feature/type is 
defined in the header file. Indeed, over time, Landlock and this related 
header file will get new fields (e.g. LANDLOCK_ACCESS_FS_REFER, 
LANDLOCK_ACCESS_FS_TRUNCATE) and type definitions.


> 
> I'm hoping to find some time to look at this over the
> holidays...

Feel free to post updates and Cc @l0kod in the related GitHub PR.

Enjoy your holidays!
  Mickaël

> 
> 
> Cheers,
> Y.
> 

Re: Landlock setup

[Yves Rutschle]

On Fri, Dec 16, 2022 at 11:34:58AM +0100, Mickaël Salaün wrote:
> You can get any Linux's mainline landlock.h [1] [...]

My problem was that I copied the syscall numbers directly
into landlock.h (I didn't want to import too many headers)
and got it wrong, so it would call system calls that didn't
exist.

The example works, I now "just" have to do the work :-)

Y.