self protect process with landlock to getting killed

self protect process with landlock to getting killed

[Jay Freyensee]

Hi I had a question for someone. Is there a way to protect a landlocked 
process from being killed by a non-landlock process?  Does that 
protection include root protection and root not being able to kill that 
landlocked process?

What about is there a way to protect the directory the landlock process 
sits in from being tampered/written-to by a non-landlock process?

I came up with the question from reading this comment in the kernel docs:

"Once a thread is landlocked, there is no way to remove its security 
policy; only adding more restrictions is allowed."

I believe you can get this protection through SELinux I was just curious 
if the landlocked gave you that as well; SELinux can be confusing to 
work with.


Thank you,

Jay

Re: self protect process with landlock to getting killed

[Mickaël Salaün]

Hi,

On 27/06/2023 18:14, Jay Freyensee wrote:
> Hi I had a question for someone. Is there a way to protect a landlocked
> process from being killed by a non-landlock process?  Does that
> protection include root protection and root not being able to kill that
> landlocked process?

Landlock is sandboxing feature, which means that it restricts a set of 
processes from accessing resources. Because it is opt-in per process 
hierarchy, it doesn't restrict non-landlocked processes from sending 
signal or tracing landlocked processes. However, other Linux security 
mechanisms (e.g., UID) might restrict this kind of interactions.

If you want to restrict a process from tampering with another process 
(i.e. ptrace restriction, not kill restriction), you need to sandbox it 
with Landlock, and the target process need to not be in the same sandbox 
or a nested one.

For now, Landlock doesn't support signal restriction. This should be 
part of a future development.

> 
> What about is there a way to protect the directory the landlock process
> sits in from being tampered/written-to by a non-landlock process?

The same principle applies: this is not possible with Landlock itself. 
The potential malicious processes should be sandboxed.


> 
> I came up with the question from reading this comment in the kernel docs:
> 
> "Once a thread is landlocked, there is no way to remove its security
> policy; only adding more restrictions is allowed."
> 
> I believe you can get this protection through SELinux I was just curious
> if the landlocked gave you that as well; SELinux can be confusing to
> work with.

SELinux enables to restrict the whole system, so it is like if every 
processes were sandboxed.

> 
> 
> Thank you,
> 
> Jay
> 
> 

Re: self protect process with landlock to getting killed

[Jay Freyensee]

>
>>
>> What about is there a way to protect the directory the landlock process
>> sits in from being tampered/written-to by a non-landlock process?
>
> The same principle applies: this is not possible with Landlock itself. 
> The potential malicious processes should be sandboxed.
>
>
Thanks for the response Mickael.  In this case, this would kind of be 
like a zero-day use case, that we wouldn't know all the malicious 
processes tampering with that process's directory up-front, we just know 
that we wouldn't want any non-landlocked process (known and unknown) 
tampering with the directory the landlocked process sits in.

Thanks,

Jay

Re: self protect process with landlock to getting killed

[Mickaël Salaün]

On 28/06/2023 17:20, Jay Freyensee wrote:
> 
> 
>>
>>>
>>> What about is there a way to protect the directory the landlock process
>>> sits in from being tampered/written-to by a non-landlock process?
>>
>> The same principle applies: this is not possible with Landlock itself.
>> The potential malicious processes should be sandboxed.
>>
>>
> Thanks for the response Mickael.  In this case, this would kind of be
> like a zero-day use case, that we wouldn't know all the malicious
> processes tampering with that process's directory up-front, we just know
> that we wouldn't want any non-landlocked process (known and unknown)
> tampering with the directory the landlocked process sits in.

If you cannot sandbox the "other" processes, then I guess all/most 
processes are potentially malicious. In this case you're indeed looking 
to reverse the protection: restrict all/most processes from tampering 
with well-defined resources. You then need to rely on a system-wide 
access control that can be put in place with different UID/GID, or other 
LSMs: SELinux, AppArmor, Smack or Tomoyo.

Regards,
  Mickaël

> 
> Thanks,
> 
> Jay
> 
>