appc / spec

App Container Specification and Tooling (archived, see https://github.com/rkt/rkt/issues/4024)
Apache License 2.0
1.26k stars 146 forks source link

spec/ace: add two new isolators for masking paths #650

Open lucab opened 8 years ago

lucab commented 8 years ago

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 commented 8 years ago

Reference https://github.com/coreos/rkt/issues/2996.

/cc @euank

jonboulle commented 8 years ago

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 commented 8 years ago

@vbatts thoughts?

vbatts commented 8 years ago

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 commented 8 years ago

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: https://github.com/systemd/systemd/pull/3685