Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

[Mickaël Salaün]

On 14/11/2016 11:35, Sargun Dhillon wrote:
> Was there a plan around getting Daniel's patches in as well? Also,
> rather than making these handles landlock-specific, can they be
> implemented in such a way where we can keep track of (some) of these
> in other types of programs?
> 

About the map of handles, this is only a new type of map so it's not
particularly Landlock-specific. Anyway, we'll see that in the third step.

 Mickaël



signature.asc
Description: OpenPGP digital signature

Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

[Sargun Dhillon]

On Sun, Nov 13, 2016 at 6:23 AM, Mickaël Salaün  wrote:
> Hi,
>
> After the BoF at LPC last week, we came to a multi-step roadmap to
> upstream Landlock.
>
> A first patch series containing the basic properties needed for a
> "minimum viable product", which means being able to test it, without
> full features. The idea is to set in place the main components which
> include the LSM part (some hooks with the manager logic) and the new
> eBPF type. To have a minimum amount of code, the first userland entry
> point will be the seccomp syscall. This doesn't imply non-upstream
> patches and should be more simple. For the sake of simplicity and to
> ease the review, this first series will only be dedicated to privileged
> processes (i.e. with CAP_SYS_ADMIN). We may want to only allow one level
> of rules at first, instead of dealing with more complex rule inheritance
> (like seccomp-bpf can do).
>
> The second series will focus on the cgroup manager. It will follow the
> same rules of inheritance as the Daniel Mack's patches does.
>
> The third series will try to bring a BPF map of handles for Landlock and
> the dedicated BPF helpers.
>
> Finally, the fourth series will bring back the unprivileged mode (with
> no_new_privs), at least for process hierarchies (via seccomp). This also
> imply to handle multi-level of rules.
>
> Right now, an important point of attention is the userland ABI. We don't
> want LSM hooks to be exposed "as is" to userland. This may have some
> future implications if their semantic and/or enforcement point(s)
> change. In the next series, I will propose a new abstraction over the
> currently used LSM hooks. I'll also propose a new way to deal with
> resource accountability. Finally, I plan to create a minimal (kernel)
> developer documentation and a test suite.
>
> Regards,
>  Mickaël
>
>
> On 26/10/2016 08:56, Mickaël Salaün wrote:
>> Hi,
>>
>> This fourth RFC brings some improvements over the previous one [1]. An 
>> important
>> new point is the abstraction from the raw types of LSM hook arguments. It is
>> now possible to call a Landlock function the same way for LSM hooks with
>> different internal argument types. Some parts of the code are revamped with 
>> RCU
>> to properly deal with concurrency. From a userland point of view, the only
>> remaining link with seccomp-bpf is the ability to use the seccomp(2) syscall 
>> to
>> load and enforce a Landlock rule. Seccomp filters cannot trigger Landlock 
>> rules
>> anymore. For now, it is no more possible for an unprivileged user to enforce 
>> a
>> Landlock rule on a cgroup through delegation.
>>
>> As suggested, I plan to write documentation for userland and kernel 
>> developers
>> with some kind of guiding principles. A remaining question is how to enforce
>> limitations for the rule creation?
>>
>>
>> # Landlock LSM
>>
>> The goal of this new stackable Linux Security Module (LSM) called Landlock is
>> to allow any process, including unprivileged ones, to create powerful 
>> security
>> sandboxes comparable to the Seatbelt/XNU Sandbox or the OpenBSD Pledge. This
>> kind of sandbox is expected to help mitigate the security impact of bugs or
>> unexpected/malicious behaviors in userland applications.
>>
>> eBPF programs are used to create a security rule. They are very limited (i.e.
>> can only call a whitelist of functions) and cannot do a denial of service 
>> (i.e.
>> no loop). A new dedicated eBPF map allows to collect and compare Landlock
>> handles with system resources (e.g. files or network connections).
>>
>> The approach taken is to add the minimum amount of code while still allowing
>> the userland to create quite complex access rules. A dedicated security 
>> policy
>> language as the one used by SELinux, AppArmor and other major LSMs involves a
>> lot of code and is usually dedicated to a trusted user (i.e. root).
>>
>>
>> # eBPF
>>
>> To get an expressive language while still being safe and small, Landlock is
>> based on eBPF. Landlock should be usable by untrusted processes and must then
>> expose a minimal attack surface. The eBPF bytecode is minimal while powerful,
>> widely used and designed to be used by not so trusted application. Reusing 
>> this
>> code allows to not reproduce the same mistakes and minimize new code  while
>> still taking a generic approach. Only a few additional features are added 
>> like
>> a new kind of arraymap and some dedicated eBPF functions.
>>
>> An eBPF program has access to an eBPF context which contains the LSM hook
>> arguments (as does seccomp-bpf with syscall arguments). They can be used
>> directly or passed to helper functions according to their types. It is then
>> possible to do complex access checks without race conditions nor inconsistent
>> evaluation (i.e. incorrect mirroring of the OS code and state [2]).
>>
>> There is one eBPF program subtype per LSM hook. This allows to statically 
>> check
>> which context access is performed by an eBPF program. This 

Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

[Alexei Starovoitov]

On Sun, Nov 13, 2016 at 6:23 AM, Mickaël Salaün  wrote:
> Hi,
>
> After the BoF at LPC last week, we came to a multi-step roadmap to
> upstream Landlock.
>
> A first patch series containing the basic properties needed for a
> "minimum viable product", which means being able to test it, without
> full features. The idea is to set in place the main components which
> include the LSM part (some hooks with the manager logic) and the new
> eBPF type. To have a minimum amount of code, the first userland entry
> point will be the seccomp syscall. This doesn't imply non-upstream
> patches and should be more simple. For the sake of simplicity and to
> ease the review, this first series will only be dedicated to privileged
> processes (i.e. with CAP_SYS_ADMIN). We may want to only allow one level
> of rules at first, instead of dealing with more complex rule inheritance
> (like seccomp-bpf can do).
>
> The second series will focus on the cgroup manager. It will follow the
> same rules of inheritance as the Daniel Mack's patches does.
>
> The third series will try to bring a BPF map of handles for Landlock and
> the dedicated BPF helpers.
>
> Finally, the fourth series will bring back the unprivileged mode (with
> no_new_privs), at least for process hierarchies (via seccomp). This also
> imply to handle multi-level of rules.
>
> Right now, an important point of attention is the userland ABI. We don't
> want LSM hooks to be exposed "as is" to userland. This may have some
> future implications if their semantic and/or enforcement point(s)
> change. In the next series, I will propose a new abstraction over the
> currently used LSM hooks. I'll also propose a new way to deal with
> resource accountability. Finally, I plan to create a minimal (kernel)
> developer documentation and a test suite.

Thanks for the summary.
That's exactly what we discussed and agreed upon.

Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

[Mickaël Salaün]

Hi,

After the BoF at LPC last week, we came to a multi-step roadmap to
upstream Landlock.

A first patch series containing the basic properties needed for a
"minimum viable product", which means being able to test it, without
full features. The idea is to set in place the main components which
include the LSM part (some hooks with the manager logic) and the new
eBPF type. To have a minimum amount of code, the first userland entry
point will be the seccomp syscall. This doesn't imply non-upstream
patches and should be more simple. For the sake of simplicity and to
ease the review, this first series will only be dedicated to privileged
processes (i.e. with CAP_SYS_ADMIN). We may want to only allow one level
of rules at first, instead of dealing with more complex rule inheritance
(like seccomp-bpf can do).

The second series will focus on the cgroup manager. It will follow the
same rules of inheritance as the Daniel Mack's patches does.

The third series will try to bring a BPF map of handles for Landlock and
the dedicated BPF helpers.

Finally, the fourth series will bring back the unprivileged mode (with
no_new_privs), at least for process hierarchies (via seccomp). This also
imply to handle multi-level of rules.

Right now, an important point of attention is the userland ABI. We don't
want LSM hooks to be exposed "as is" to userland. This may have some
future implications if their semantic and/or enforcement point(s)
change. In the next series, I will propose a new abstraction over the
currently used LSM hooks. I'll also propose a new way to deal with
resource accountability. Finally, I plan to create a minimal (kernel)
developer documentation and a test suite.

Regards,
 Mickaël


On 26/10/2016 08:56, Mickaël Salaün wrote:
> Hi,
> 
> This fourth RFC brings some improvements over the previous one [1]. An 
> important
> new point is the abstraction from the raw types of LSM hook arguments. It is
> now possible to call a Landlock function the same way for LSM hooks with
> different internal argument types. Some parts of the code are revamped with 
> RCU
> to properly deal with concurrency. From a userland point of view, the only
> remaining link with seccomp-bpf is the ability to use the seccomp(2) syscall 
> to
> load and enforce a Landlock rule. Seccomp filters cannot trigger Landlock 
> rules
> anymore. For now, it is no more possible for an unprivileged user to enforce a
> Landlock rule on a cgroup through delegation.
> 
> As suggested, I plan to write documentation for userland and kernel developers
> with some kind of guiding principles. A remaining question is how to enforce
> limitations for the rule creation?
> 
> 
> # Landlock LSM
> 
> The goal of this new stackable Linux Security Module (LSM) called Landlock is
> to allow any process, including unprivileged ones, to create powerful security
> sandboxes comparable to the Seatbelt/XNU Sandbox or the OpenBSD Pledge. This
> kind of sandbox is expected to help mitigate the security impact of bugs or
> unexpected/malicious behaviors in userland applications.
> 
> eBPF programs are used to create a security rule. They are very limited (i.e.
> can only call a whitelist of functions) and cannot do a denial of service 
> (i.e.
> no loop). A new dedicated eBPF map allows to collect and compare Landlock
> handles with system resources (e.g. files or network connections).
> 
> The approach taken is to add the minimum amount of code while still allowing
> the userland to create quite complex access rules. A dedicated security policy
> language as the one used by SELinux, AppArmor and other major LSMs involves a
> lot of code and is usually dedicated to a trusted user (i.e. root).
> 
> 
> # eBPF
> 
> To get an expressive language while still being safe and small, Landlock is
> based on eBPF. Landlock should be usable by untrusted processes and must then
> expose a minimal attack surface. The eBPF bytecode is minimal while powerful,
> widely used and designed to be used by not so trusted application. Reusing 
> this
> code allows to not reproduce the same mistakes and minimize new code  while
> still taking a generic approach. Only a few additional features are added like
> a new kind of arraymap and some dedicated eBPF functions.
> 
> An eBPF program has access to an eBPF context which contains the LSM hook
> arguments (as does seccomp-bpf with syscall arguments). They can be used
> directly or passed to helper functions according to their types. It is then
> possible to do complex access checks without race conditions nor inconsistent
> evaluation (i.e. incorrect mirroring of the OS code and state [2]).
> 
> There is one eBPF program subtype per LSM hook. This allows to statically 
> check
> which context access is performed by an eBPF program. This is needed to deny
> kernel address leak and ensure the right use of LSM hook arguments with eBPF
> functions. Moreover, this safe pointer handling removes the need for runtime
> check or abstract data, which 

Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

[Mickaël Salaün]

On 26/10/2016 18:56, Mickaël Salaün wrote:
> 
> On 26/10/2016 16:52, Jann Horn wrote:
>> On Wed, Oct 26, 2016 at 08:56:36AM +0200, Mickaël Salaün wrote:
>>> The loaded Landlock eBPF programs can be triggered by a seccomp filter
>>> returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed 
>>> from
>>> a seccomp filter to eBPF programs. This allow flexible security policies
>>> between seccomp and Landlock.
>>
>> Is this still up to date, or was that removed in v3?
>>
> 
> I forgot to remove this part. In this v4 series, as describe in the
> (small) patch 11/18, a Landlock rule cannot be triggered by a seccomp
> filter. So there is no more RET_LANDLOCK nor cookie.
> 

Here is an up-to-date version:

# Use case scenario

First, a process needs to create a new dedicated eBPF map containing handles.
This handles are references to system resources (e.g. file or directory). They
are grouped in one or multiple maps to be efficiently managed and checked in
batches. This kind of map can be passed to Landlock eBPF functions to compare,
for example, with a file access request.

First, a task need to create or receive a Landlock rule. This rule is a
dedicated eBPF program tied to one of the Landlock hooks, which are a subset of
LSM hooks. Once loaded, a Landlock rule can be enforced through the seccomp(2)
syscall for the current thread and its (future) children, like a seccomp
filter.

Another way to enforce a Landlock security policy is to attach Landlock rules
to a cgroup. All the processes in this cgroup will then be subject to this
policy.

A triggered Landlock eBPF program can allow or deny an access, according to
its subtype (i.e. LSM hook), thanks to errno return values.




signature.asc
Description: OpenPGP digital signature

Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

[Mickaël Salaün]

On 26/10/2016 16:52, Jann Horn wrote:
> On Wed, Oct 26, 2016 at 08:56:36AM +0200, Mickaël Salaün wrote:
>> The loaded Landlock eBPF programs can be triggered by a seccomp filter
>> returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed 
>> from
>> a seccomp filter to eBPF programs. This allow flexible security policies
>> between seccomp and Landlock.
> 
> Is this still up to date, or was that removed in v3?
> 

I forgot to remove this part. In this v4 series, as describe in the
(small) patch 11/18, a Landlock rule cannot be triggered by a seccomp
filter. So there is no more RET_LANDLOCK nor cookie.



signature.asc
Description: OpenPGP digital signature

Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

[Jann Horn]

On Wed, Oct 26, 2016 at 08:56:36AM +0200, Mickaël Salaün wrote:
> The loaded Landlock eBPF programs can be triggered by a seccomp filter
> returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed 
> from
> a seccomp filter to eBPF programs. This allow flexible security policies
> between seccomp and Landlock.

Is this still up to date, or was that removed in v3?


signature.asc
Description: Digital signature

[RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

[Mickaël Salaün]

Hi,

This fourth RFC brings some improvements over the previous one [1]. An important
new point is the abstraction from the raw types of LSM hook arguments. It is
now possible to call a Landlock function the same way for LSM hooks with
different internal argument types. Some parts of the code are revamped with RCU
to properly deal with concurrency. From a userland point of view, the only
remaining link with seccomp-bpf is the ability to use the seccomp(2) syscall to
load and enforce a Landlock rule. Seccomp filters cannot trigger Landlock rules
anymore. For now, it is no more possible for an unprivileged user to enforce a
Landlock rule on a cgroup through delegation.

As suggested, I plan to write documentation for userland and kernel developers
with some kind of guiding principles. A remaining question is how to enforce
limitations for the rule creation?


# Landlock LSM

The goal of this new stackable Linux Security Module (LSM) called Landlock is
to allow any process, including unprivileged ones, to create powerful security
sandboxes comparable to the Seatbelt/XNU Sandbox or the OpenBSD Pledge. This
kind of sandbox is expected to help mitigate the security impact of bugs or
unexpected/malicious behaviors in userland applications.

eBPF programs are used to create a security rule. They are very limited (i.e.
can only call a whitelist of functions) and cannot do a denial of service (i.e.
no loop). A new dedicated eBPF map allows to collect and compare Landlock
handles with system resources (e.g. files or network connections).

The approach taken is to add the minimum amount of code while still allowing
the userland to create quite complex access rules. A dedicated security policy
language as the one used by SELinux, AppArmor and other major LSMs involves a
lot of code and is usually dedicated to a trusted user (i.e. root).


# eBPF

To get an expressive language while still being safe and small, Landlock is
based on eBPF. Landlock should be usable by untrusted processes and must then
expose a minimal attack surface. The eBPF bytecode is minimal while powerful,
widely used and designed to be used by not so trusted application. Reusing this
code allows to not reproduce the same mistakes and minimize new code  while
still taking a generic approach. Only a few additional features are added like
a new kind of arraymap and some dedicated eBPF functions.

An eBPF program has access to an eBPF context which contains the LSM hook
arguments (as does seccomp-bpf with syscall arguments). They can be used
directly or passed to helper functions according to their types. It is then
possible to do complex access checks without race conditions nor inconsistent
evaluation (i.e. incorrect mirroring of the OS code and state [2]).

There is one eBPF program subtype per LSM hook. This allows to statically check
which context access is performed by an eBPF program. This is needed to deny
kernel address leak and ensure the right use of LSM hook arguments with eBPF
functions. Moreover, this safe pointer handling removes the need for runtime
check or abstract data, which improves performances. Any user can add multiple
Landlock eBPF programs per LSM hook. They are stacked and evaluated one after
the other (cf. seccomp-bpf).


# LSM hooks

Unlike syscalls, LSM hooks are security checkpoints and are not architecture
dependent. They are designed to match a security need associated with a
security policy (e.g. access to a file). Exposing parts of some LSM hooks
instead of using the syscall API for sandboxing should help to avoid bugs and
hacks as encountered by the first RFC. Instead of redoing the work of the LSM
hooks through syscalls, we should use and expose them as does policies of
access control LSM.

Only a subset of the hooks are meaningful for an unprivileged sandbox mechanism
(e.g. file system or network access control). Landlock uses an abstraction of
raw LSM hooks, which allow to deal with possible future API changes of the LSM
hook API. Moreover, thanks to the ePBF program typing (per LSM hook) used by
Landlock, it should not be hard to make such evolutions backward compatible.


# Use case scenario

First, a process needs to create a new dedicated eBPF map containing handles.
This handles are references to system resources (e.g. file or directory) and
grouped in one or multiple maps to be efficiently managed and checked in
batches. This kind of map can be passed to Landlock eBPF functions to compare,
for example, with a file access request. The handles are only accessible from
the eBPF programs created by the same thread.

The loaded Landlock eBPF programs can be triggered by a seccomp filter
returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed from
a seccomp filter to eBPF programs. This allow flexible security policies
between seccomp and Landlock.

Another way to enforce a Landlock security policy is to attach Landlock
programs to a dedicated cgroup. All the processes in this cgroup will then be