The construction of a Landlock ruleset is based on an authorization list model. Thus, in order to sandbox an application, all necessary resources and their associated permissions must be first established (directories being recursively included).
It would be great to be able to deny itself access to specific resources (i.e. Give a RO access to / but deny access to /home).
Another benefit of this approach would be ruleset refining, in other word, dropping an access rule after ruleset enforcement.
To achieve this goal with the current API, the original ruleset contents and restrictions have to be maintained aside (i.e. an array of structure containing paths and their restrictions).
Once the task want to refines it restrictions, it can evict it from the maintained array, build back a ruleset and enforce it.
Maintaining such a data structure is cumbersome and would be made much easier by rule deny listing. (see #25)
For a first implementation, I think every Landlocks filesystem actions could be denied to the evicted resource.
Extra care should be given in order to avoid sandbox escapes, i.e. renaming a file in order to access it.
A deny rule should be applied only on resources already authorized in a Landlock ruleset.
@l0kod do you think of anything to add ?
The construction of a Landlock ruleset is based on an authorization list model. Thus, in order to sandbox an application, all necessary resources and their associated permissions must be first established (directories being recursively included).
It would be great to be able to deny itself access to specific resources (i.e. Give a RO access to / but deny access to /home).
Another benefit of this approach would be ruleset refining, in other word, dropping an access rule after ruleset enforcement.
To achieve this goal with the current API, the original ruleset contents and restrictions have to be maintained aside (i.e. an array of structure containing paths and their restrictions).
Once the task want to refines it restrictions, it can evict it from the maintained array, build back a ruleset and enforce it.
Maintaining such a data structure is cumbersome and would be made much easier by rule deny listing. (see #25)
For a first implementation, I think every Landlocks filesystem actions could be denied to the evicted resource.
Extra care should be given in order to avoid sandbox escapes, i.e. renaming a file in order to access it.
A deny rule should be applied only on resources already authorized in a Landlock ruleset.
@l0kod do you think of anything to add ?