specs-go/config: add Landlock LSM support

[kailun-qin]

Linux kernel 5.13 adds support for Landlock Linux Security Module (LSM). This allows unprivileged processes to create safe security sandboxes that can securely restrict the ambient rights (e.g. global filesystem access) for themselves.

https://github.com/opencontainers/runtime-spec/issues/1110

Signed-off-by: Kailun Qin [email protected]

[h-vetinari]

So I'm of two minds about how much of the Landlock ruleset language we want to embed in the runtime-spec. I haven't looked too deeply into the version of Landlock that was merged -- is there any serialisation format they describe? Or is it like libseccomp where it's a bunch of function calls and we need to create our own way of describing it?

[...]

CC @l0kod

[BoardzMaster]

Having this format of Landlock rules I think is enough (like @kailun-qin suggested)

1. Go LibLandlock is already implemented by Günther Noack https://github.com/gnoack/golandlock. It can be used in runc.
2. Another issue is the future support for containerd/k8s. Here there must be serialization format like @cyphar addressed in his comment ( grpc mechanisms in particular)

Mickaël Salaün, please give your opinion CC @l0kod

[AkihiroSuda]

@kailun-qin Do you have a POC implementation of runc/crun to verify this design?

[l0kod]

Sorry for the delay, I missed the GitHub notification. Thanks for working on this, I'm happy to help! However, I'm not familiar with runtime-spec, my suggestions may not be accurate.

To be sure everyone is on the same page, I want to say that Landlock may not currently be used in a generic container because of the reparenting limitation. I plan to address this in the following months. However, I think it is a good idea to start the integration now and that the current status can still be useful to users.

The goal of Landlock is to give (for this use case) the ability to container managers to handle access rights independently to the parent system configuration (i.e. it doesn't require admin rights). It seems that options such as maskedPaths and readonlyPaths have a similar purpose (but they use the namespace features underneath). However, because runtime-spec is close to the underlying kernel/OS, it seems that it makes sense to have a specific "landlock" object for Linux.

FYI, to be able to use Landlock, the noNewPrivileges option must be enabled. It may be a good idea to hint the user and error out if Landlock is configured without this option to avoid false sense of security.

Because a kernel may not support Landlock (because the kernel is too old, or Landlock is not configured, or not enabled at boot time), I would advise to follow a best-effort security approach, which is to just drop a warning and continue interpreting the configuration by default. However, it may be wise to let users choose to enforce Landlock restrictions for specific use cases (e.g. when we create a configuration for our own systems that we know should support Landlock). I don't know how this is currently handled for seccomp though, but I guess the behavior should be the same.

How do you plan to use the "abi" field?

If you want to follow Landlock development, you can subscribe to the appropriate mailing list: https://subspace.kernel.org/lists.linux.dev.html. I'll send news soon.

[BoardzMaster]

I suggest using a simplified version of a file/dir access rules like RW, RO. In this case, we could use RODirs()...RwFiles() restrict path options from the golandlock library https://github.com/gnoack/golandlock and a spec config.json file would be like this:

It will be more convenient for a user.

Mickaël Salaün, please give your opinion CC @l0kod

[l0kod]

I suggest using a simplified version of a file/dir access rules like RW, RO. In this case, we could use RODirs()...RwFiles()

RW and RO are misleading because there is not yet full support for all read and write operations on the filesystem. Moreover, runtime-spec seems to deal with low-level system config (e.g. mount options). I think that maintaining a high-level and evolving configuration will not fit with the purpose of runtime-spec.

However, it is still possible to create variables containing a pre-defined set of access rights.

[gnoack]

I suggest using a simplified version of a file/dir access rules like RW, RO. In this case, we could use RODirs()...RwFiles()

RW and RO are misleading because there is not yet full support for all read and write operations on the filesystem. Moreover, runtime-spec seems to deal with low-level system config (e.g. mount options). I think that maintaining a high-level and evolving configuration will not fit with the purpose of runtime-spec.

However, it is still possible to create variables containing a pre-defined set of access rights.

+1

The intent with ROFiles() and friends is to provide a way to coarsely permit operations and have the permissions "grow" along when new Landlock ABI versions become available. I'm hoping that in most cases it will only be needed to increment the used Landlock ABI version from time to time, and leaving the ROFiles() and similar rules untouched. But my compatibility assumptions are difficult to test, and @l0kod has a better hunch what the future might bring.

Please open a feature request on golandlock if you want more direct access for specifying ruleset.handledAccessFS. (Right now, it's implicitly set to the "best possible" value in the golandlock.V1 constant. The only reason this is not exposed so far was because I could not imagine a use case for it...)

[kailun-qin]

Thank you for all your inputs and comments! @l0kod @cyphar @BoardzMaster @h-vetinari @AkihiroSuda @gnoack

I've updated with a new version mainly w/ below changes based on the feedbacks:

• Use an object with rule-type keys instead of an array of rules with specific types to make configuration lighter.
• Simplify the access rights consts as they are scoped and typed by the LandlockFSAction.
• Update some field comments and add elaborations on the usage of abi etc.
• Misc minor fixes.

@AkihiroSuda Regarding POC implementation, we're working on it based on runc and golandlock. We'll submit PRs for review once it's ready.

Please kindly take another look. Let me know if any further suggestions. Thanks!

[AkihiroSuda]

What do we need to move this forward?

[vbatts]

@AkihiroSuda the discussion looks good and healthy. And it looks like implementations are iterating to find consensus and polish out issues found. I haven't seen any feedback that should stop this issue from a final review.

[kailun-qin]

config schema must be updated as well

Updated, thanks!

[AkihiroSuda]

Could you consider squashing commits?

[kailun-qin]

Could you consider squashing commits?

Squashed and rebased, PTAL, thanks!

[AkihiroSuda]

@kailun-qin What's current status of this?