[CRIU] [PATCH 0/1] process attribute support for Landlock

[Günther Noack]

Hi!

On Wed, Mar 15, 2023 at 10:56:03AM +0100, Mickaël Salaün wrote:
> On 08/03/2023 23:25, Shervin Oloumi wrote:
> > Thanks all for the feedback. This is in reply to Mickaël, but should
> > answer Günther's questions as well.
> > 
> > > It would help to know exactly what are your needs short term, and long
> > > term. As Günther is wondering, what about nested sandboxing?
> > 
> > Our plan is to use the "landlocked" process attribute defined in the
> > patch to determine the sandbox state of the system processes and send
> > information to our metrics server regarding Landlock coverage. For
> > example, the percentage of processes on the system that are sandboxed
> > using Landlock.
> > 
> > Given that we use Landlock in a very specific and controlled way, we
> > are not concerned about the inheritance behavior and nested policies,
> > at least for the use case of metrics. When daemons are launched in
> > ChromiumOS, they have a pre-defined sandboxing configuration that
> > dictates whether Landlock should be applied or not. So this attribute
> > would help us verify that the processes running on devices in the wild
> > indeed have the general sandboxing state that we expect and the
> > reality matches our expectation.
> > 
> > Long-term, it would be useful to learn more information about domains
> > and policies through the process attribute interface, but we do not
> > currently have a need for that, apart from maybe doing troubleshooting
> > when defining Landlock rules for system daemons.
> 
> OK, it makes sense.

Fair enough.  I missed the fact that this was about the OS rather than
the browser.

Still, out of curiosity: Hypothetically, if you were to expose the
number of stacked Landlock policies instead of the boolean in that
place -- would there be any drawbacks to that which I'm overlooking?

It seems to me, superficially, that the implementation should be
similarly simple, it would be useful in more cases where Landlock
users do not have control over the full OS, and I can't currently see
any cases where having a number instead of a boolean would complicate
the usage from userspace?  Am I missing something?

(But in any case, the boolean is also fine I think.)


> > > Here are the guiding principles I think would make sense:
> > > 1. A sandboxed thread shall not be able to directly know if it is
> > > sandbox nor get any specific information from it's restrictions. The
> > > reason for this principle is to avoid applications to simply jump to
> > > conclusions (and change behavior) if they see that they are sandboxed
> > > with Landlock, instead of trying to access resources and falling back
> > > accordingly. A thread should only be able to inspect its
> > > own/children/nested domains.

(Small remark:

Doing anything differently depending on whether and how you are
landlocked is definitely an antipattern which we should not encourage.
But I'm not sure whether we can hide the fact very easily.

It's already possible for a thread to detect whether it is landlocked,
by using this hack: Create a new thread and then in that thread count
how many additional sandboxes you can stack on top.

If you have knowledge about what Landlock configuration you are
looking for, it will be even easier to detect.

I hope noone takes the above example as inspiration.)

–Günther