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 <#8 (comment)>, 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.