Compatibility mode

[l0kod]

Update Ruleset::new() to take a CompatMode argument, and add the required dependencies to handle incompatibility consequences with if_unmet(), CompatAccess...

See rationale here: https://fosdem.org/2023/schedule/event/rust_backward_and_forward_compatibility_for_security_features/

Proposal:

• add a new (alternative) constructor to Ruleset to be able to enforce a "hard requirement" for everything (set to "best effort" with the default() constructor: Use Ruleset::default() instead of Ruleset::new() #44);
• add a method to access rights to be able to set the "soft requirement" property.

Example with current API:

Ruleset::new()
    .set_compatibility(CompatLevel::HardRequirement)
    .handle_access(AccessFs::from_all(ABI::V1))?
    .set_compatibility(CompatLevel::SoftRequirement)
    .handle_access(AccessFs::Refer)?
    .set_compatibility(CompatLevel::HardRequirement)

Same example with the proposed API:

Ruleset::new(CompatMode::ErrorIfUnmet) 
    .handle_access(AccessFs::from_all(ABI::V1))?
    .handle_access(AccessFs::Refer.if_unmet(Consequence::DisableRuleset))?

Example with the best effort behavior:

Ruleset::default() 
    .handle_access(AccessFs::from_all(ABI::V1))?
    .handle_access(AccessFs::Refer)?

This design is simpler and it removes the mutable builder property (multiple .set_compatibility() calls) that may be confusing and error prone.

I started working on that a while ago but the code is still WIP.

[praveen-pk]

From usage stand point, it would be better to make ErroIfUnmet the default and BestEffort user selectable. If a use case needs maximum compatibility, developers can proactively choose BestEffort during development.

By making BestEffort default, users may get the false sense that the application is sandboxed, when it really isn't.

[l0kod]

From usage stand point, it would be better to make ErroIfUnmet the default and BestEffort user selectable. If a use case needs maximum compatibility, developers can proactively choose BestEffort during development.

As explained in the documentation, the best-effort approach should be the default. The main point being that app developers don't know the kernel on which their app is running, and we want to protect users as much as possible.

By making BestEffort default, users may get the false sense that the application is sandboxed, when it really isn't.

I think most users trust (or hope) developers implement the best secure solution for their usage. Most of the time users would not get a false sense of security because they may not see any security message implying that.

This is different when developping and testing a sandboxed software where we can control the kernel version and make sure it works (and restrict) as expected. This is why it is still handy to be able to change this behavior at run (or start) time.

[praveen-pk]

(Sorry about the delay with my response, I missed your previous comment.)

From usage stand point, it would be better to make ErroIfUnmet the default and BestEffort user selectable. If a use case needs maximum compatibility, developers can proactively choose BestEffort during development.

As explained in the documentation, the best-effort approach should be the default. The main point being that app developers don't know the kernel on which their app is running, and we want to protect users as much as possible.

Generally, I agree that software should take best-effort security approach when deployed. My only concern is about what the default value configured for CompatMode.

As a concrete example, let's assume a developer built an application with ABI:V3 and set CompatMode to BestEffort. If the kernel on the user end only supports ABI:V1, Landlock doesn't limit LANDLOCK_ACCESS_FS_REFER and LANDLOCK_ACCESS_FS_TRUNCATE operations. In such a case, the end-user might get the false impression that his/her application is sufficiently sandboxed, when the application can still perform above operations.

If the default mode for CompatMode is set to ErroIfUnmet, the application will fail to run when started in the user end, as the underlying kernel doesn't support all the required features. Now the user can pass a --compat-mode=yes(like) option to the application to use whatever features are available. In this case user is fully aware that their application is running in CompatMode and that means the application isn't locked down with all the features it can be.

As I wrote this down, I started thinking it may be unreasonable to expect every application to add '--compat-mode' argument and pass appropriate flags to Landlock. This could be a reason to choose CompatMode as the default.

By making BestEffort default, users may get the false sense that the application is sandboxed, when it really isn't.

I think most users trust (or hope) developers implement the best secure solution for their usage. Most of the time users would not get a false sense of security because they may not see any security message implying that.

This is different when developping and testing a sandboxed software where we can control the kernel version and make sure it works (and restrict) as expected. This is why it is still handy to be able to change this behavior at run (or start) time.

Understood.

[l0kod]

(Sorry about the delay with my response, I missed your previous comment.)

From usage stand point, it would be better to make ErroIfUnmet the default and BestEffort user selectable. If a use case needs maximum compatibility, developers can proactively choose BestEffort during development.

As explained in the documentation, the best-effort approach should be the default. The main point being that app developers don't know the kernel on which their app is running, and we want to protect users as much as possible.

Generally, I agree that software should take best-effort security approach when deployed. My only concern is about what the default value configured for CompatMode.

As a concrete example, let's assume a developer built an application with ABI:V3 and set CompatMode to BestEffort. If the kernel on the user end only supports ABI:V1, Landlock doesn't limit LANDLOCK_ACCESS_FS_REFER and LANDLOCK_ACCESS_FS_TRUNCATE operations. In such a case, the end-user might get the false impression that his/her application is sufficiently sandboxed, when the application can still perform above operations.

What is best? To protect users as much as possible (according to their running kernel), or to only protect users that are using the same kernel version as the developer?

Good sandboxing is transparent sandboxing, so users should not notice any difference. So getting a false impression of security would not make much sense is this cases. However, thanks to this crate's error codes, developers can still inform users that they should update their kernel to get a better protection.

If the default mode for CompatMode is set to ErroIfUnmet, the application will fail to run when started in the user end, as the underlying kernel doesn't support all the required features.

In this case, most users would just try to disable sandboxing to get a working application, and I understand them. For instance, we can look for the number of questions for how to disable SELinux because something is not working as expected.

Now the user can pass a --compat-mode=yes(like) option to the application to use whatever features are available. In this case user is fully aware that their application is running in CompatMode and that means the application isn't locked down with all the features it can be.

This is indeed one way to do it, but I prefer by default for things to just work, and optionally print a warning.

As I wrote this down, I started thinking it may be unreasonable to expect every application to add '--compat-mode' argument and pass appropriate flags to Landlock. This could be a reason to choose CompatMode as the default.

Indeed. We should make it simpler to protect most users by default.

By making BestEffort default, users may get the false sense that the application is sandboxed, when it really isn't.

I think most users trust (or hope) developers implement the best secure solution for their usage. Most of the time users would not get a false sense of security because they may not see any security message implying that.
This is different when developping and testing a sandboxed software where we can control the kernel version and make sure it works (and restrict) as expected. This is why it is still handy to be able to change this behavior at run (or start) time.

Understood.