Signals control

[l0kod]

A sandboxed process is currently not restricted to send signals (e.g. SIGKILL) to processes outside the sandbox. A simple way to control that would be to scope signals the same way ptrace is restricted (but this time it would be opt-in).

See https://lore.kernel.org/all/20231023.ahphah4Wii4v@digikod.net/

Approach similar to #7

v2: https://lore.kernel.org/all/cover.1722966592.git.fahimitahera@gmail.com/ v1: https://lore.kernel.org/all/36958dbc486e1f975f4d4ecdfa51ae65c2c4ced0.1720213293.git.fahimitahera@gmail.com/

[maryagiamah]

Hello, can I work on this ?

[l0kod]

Hi @maryagiamah! Yes, you can start working on signals control.

[l0kod]

What is your plan to work on this?

[maryagiamah]

I have little idea about what it entails as I have experimented with signals prior but I am still reading up on what the task is all about. Do you have any route or path I should go searching for?

On Thu, 7 Mar 2024, 09:50 Mickaël Salaün, @.***> wrote:

What is your plan to work on this?

— Reply to this email directly, view it on GitHub https://github.com/landlock-lsm/linux/issues/8#issuecomment-1982989919, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2PHWBHPIBGLFDMV6Q62P63YXAS5LAVCNFSM6AAAAABCAZJ4VOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBSHE4DSOJRHE . You are receiving this because you were assigned.Message ID: @.***>

[l0kod]

I have little idea about what it entails as I have experimented with signals prior but I am still reading up on what the task is all about. Do you have any route or path I should go searching for?

You first need to familiarize yourself with the Linux kernel development as explained in the Outreachy documentation. Then, you can start tweaking the code and test it with the test tools. If you have questions about that, please send emails to the Outreachy mailing list (CCing me and @pcmoore).

Before patching the kernel, you can start by thinking about attack scenarios using signals, describing them, and write such tests in a new file here.

About the kernel changes, we need to add a new scoped field to the landlock_ruleset_attr struct. This field will optionally contain a LANDLOCK_RULESET_SCOPED_SIGNAL flag to specify that this ruleset will deny any signal from within the sandbox to its parents (i.e. any parent sandbox or not-sandboxed processes).

This kind of restriction should be pretty similar to the ptrace ones, but we need to keep in mind that not all layers (i.e. nested sandboxes) of a Landlock domain may have this restriction. It could be seen as a roadblock for signals.

There is an LSM hook dedicated to control signals, and the Landlock scope logic is defined in ptrace.c (being renamed to task.c).

This GitHub issue is dedicated to track progress on signal control. As a reminder, no Linux kernel code change nor review should happen on GitHub because kernel reviewers are only following the dedicated mailing lists.

[l0kod]

Any news @maryagiamah?

[tahifahimi]

V1: https://lore.kernel.org/outreachy/36958dbc486e1f975f4d4ecdfa51ae65c2c4ced0.1720213293.git.fahimitahera@gmail.com/T/#t

[l0kod]

Merged in https://github.com/landlock-lsm/linux/commit/e1b061b444fb01c237838f0d8238653afe6a8094, but a test is still missing to align with the #7 tests.

[l0kod]

Related syzkaller change:

• https://github.com/google/syzkaller/pull/5350

[gnoack]

Related go-landlock PR: https://github.com/landlock-lsm/go-landlock/pull/33

During this PR, I discovered that signal scoping is potentially at odds with the way how Landlock gets enforced in multithreaded applications. Because landlock_restrict_self is inherently a single-threaded operation, in go-landlock, we use libpsx. This library implements the enforcement for all threads, but it does that by registering a special signal handler on all threads and then letting all threads do landlock_restrict_self individually. As a consequence:

• Landlock domains on different OS threads are technically speaking enforced separately from each other, and are different Landlock domains as far as the kernel is concerned. ==> When signal scopes are enabled, the separate OS threads of that process can not send each other signals any more.
• Because libpsx also in itself uses signals between these threads to enforce Landlock rulesets, libpsx can not be used correctly any more, affecting operations like (a) further landlock enforcement and (b) other psx-based glibc functionality such as setuid(2) and friends (compare setuid(2) VERSIONS section and nptl(7))