spec/ace: add two new isolators for masking paths

[lucab]

This is a request for two new isolators, useful for making paths unreachable or read-only.
This follows concepts already present in OCI config and in rkt contaiment.

1. Inaccessible paths
   • scope: per-app
   • name: environment/masked-paths
   • value: array of inaccessible paths
   • NOTES: absolute paths; ignore single entry if target path doesn't exit
2. Read-Only paths
   • scope: per-app
   • name: environment/readonly-paths
   • value: array of RO paths
   • NOTES: absolute paths; ignore single entry if target path doesn't exit

Example:

{
  "name": "environment/masked-paths",
  "value": {
    [
      "/proc/cpuinfo",
      "/foo"
    ]
  }
}

{
  "name": "environment/readonly-paths",
  "value": {
    [
      "/proc/swaps",
      "/bar"
    ]
  }
}

Up for discussion: better isolators category/name?

[lucab]

Reference rkt/rkt#2996.

/cc @euank

[jonboulle]

At first blush this sounds awkward because it seems like something that should really be handled in the filesystem layer; but I accept that doesn't facilitate all these use cases. This seems okay to me, though would be nice to get another opinion.

[jonboulle]

@vbatts thoughts?

[vbatts]

i like the concepts. IIRC, i was in favor of a blacklist path approach in addition to pathWhitelist and ACE currently has. But whether masking the files instead of removing them? I'm not sure which would be better.

Regardless, for both of these features, I'd be interested to see how the wording will be enforced for implementations. Because if a path is masked or made read-only, presumably by a bind mount or similar, then a container would have to ensure not having umount() capability otherwise it is pointless (Granted that implies CAP_SYS_ADMIN, but still)

Also, does masked imply that they can't see the path? or that they cannot read from the path? I'm not really clear

[iaguis]

i like the concepts. IIRC, i was in favor of a blacklist path approach in addition to pathWhitelist and ACE currently has. But whether masking the files instead of removing them? I'm not sure which would be better.

AFAIK the files we want to blacklist here are files that won't be present in the image (/proc/something or /sys/fs/something) so I don't think it should be related to pathWhitelist or an eventual pathBlacklist.

Also, does masked imply that they can't see the path? or that they cannot read from the path? I'm not really clear

systemd implementation for reference: systemd/systemd#3685