Make Restrict() future-proof

[gnoack]

This package does not provide stability guarantees yet, and we need to fix the API so that we can provide these guarantees.

Things I'd like to fix:

• Arguments: When calling Restrict, it's difficult to tell apart which of the arguments is which. They all have the same type.
• Flexibility: There is little flexibility to use different sets of permissions other than the four built-in ones. (Also see bug #3)
• Future Landlock compatibility: The backwards compatibility story for future versions of Landlock is unclear: To make sure that calling programs don't break when golandlock starts supporting a future Landlock ABI v2, callers will need to take action to update to new versions at some point.
• Old kernel compatibility: The backwards compatibility story for older kernels is unclear: As @l0kod pointed out, as soon as Landlock will have multiple ABI levels, there will be a use case for graceful degradation on old kernels, where the Restrict() call should lock permissions down as much as possible given the kernel that it's running on. Other users might want to still fail in that case though.

Prior art for backwards compatibility: @l0kod's rust-landlock supports multiple backwards compatibility strategies. (See ErrorThreshold enum)

[gnoack]

Future Landlock Compatibility

Main risk: Migrating from Landlock ABI N to ABI N+1 could lock down the calling process more than originally intended.

Migration between Landlock ABIs should therefore be explicit, as it can be a potentially breaking change.

I assume that for most users it should not break in practice though... the use cases I've come across often only rely on basic file operations, which are already supported in Landlock V1.

Option A: Use Go module versioning to track Landlock ABI versions

We could make the Go module version be the same as the used Landlock ABI version.

Go packages are supposed to give compatibility guarantees within major versions (doc), but an upgrade between major versions is a step where library users are naturally supposed to double check that it keeps working.

Pros:

• Requires no explicit concept of ABI version at the code layer. This would be good, because in the long run, the feature set should stabilize anyway, and then it's just baggage to make things so explicit.
• Upgrading to new Landlock versions would ideally happen as part of the regular developer workflow.

Cons:

• Users might not realize that they should upgrade every now and then.

Option B: Ask users to pass their desired ABI version

Ask users to pass "V1/V2" into the Restrict() function. That would make it very explicit what's happening.

Pros:

• Users realize what they are doing when they read the documentation for the first time.
• There could be an explicit option for "enforce the best path restrictions possible" for users who don't access paths other than the mentioned ones at all, and who want to upgrade on the fly when a new version of golandlock is released.
• The same versioning enum could also be used as the returned value to indicate the level of graceful downgrades (see below)

Cons:

• It's a bit more explicit.

[gnoack]

Old kernel compatibility

The scenario is that Restrict() is called on a kernel that has an older version of Landlock, or where Landlock is not supported.

The use cases I know of are:

• Graceful downgrade: For software whose authors do not control the deployment environment. (for example: desktop software)
• Strict mode: For software whose authors want the security and control the deployment environment enough to know that Landlock is installed at the required version. (That might include various software-as-a-service deployments)

Option A: Make the mode (graceful downgrade / strict) a parameter?

Option B: Always gracefully downgrade, but return an indicator whether it was downgraded

That would make it possible for users to tell whether a downgrade happened and react accordingly:

downgraded, err := golandlock.Restrict(...)
if err != nil {
  // ...
}
if downgraded {
  panic("Could not enforce Landlock rules")
}

Assumption: When users use the strict mode, they do it because they want to panic or log.Fatal otherwise. Maybe what is needed is not to always run in strict mode, but to just make it detectable what level of enforcement Landlock managed to enforce.

[gnoack]

I consider the above change to be OK for fixing the "arguments" and "flexibility" concerns. Feedback is welcome.

[gnoack]

I consider backwards and forwards-compatibility to be appropriately addressed with these changes.

[l0kod]

Main risk: Migrating from Landlock ABI N to ABI N+1 could lock down the calling process more than originally intended.

Migration between Landlock ABIs should therefore be explicit, as it can be a potentially breaking change.

Just to be clear, future (kernel) Landlock versions will always be compatible with older versions (e.g. the default behavior or implicit options will never change). This is required for (simple) backward compatibility (i.e. by avoiding user space to give an ABI version to the kernel) and to get a deterministic access-control.

[l0kod]

Comment about AccessFSRoughlyRead: https://github.com/gnoack/golandlock/commit/f6bba1285ffd2c64b2b8774876c29c62213d1e5a#r53543969

[l0kod]

Comment about VMax: https://github.com/gnoack/golandlock/commit/da2b49f57ce238379d93496f1c3ed843125e7536#r53544451