96 ms·

One thing I also find sorely lacking in Docker is the ability to run your containers with the appropriate seccomp privileges (in order to enforce Principle of L

One thing I also find sorely lacking in Docker is the ability to run your containers with the appropriate seccomp privileges (in order to enforce Principle of Least Authority). I know this is possible with Docker, but it's not really done much in practice because of various difficulties. I wonder how difficult it would be to do that with your tool?

syrusakbary 7y ago
Since Wasmer is in control of all the syscalls its actually quite easy to manage the privileges in a more fine-grained way (think on CloudABI permissions on top of your containers)
- anaphor 7y ago
  That sounds really interesting. I'm going to check it out. Thanks for working on this!
nwmcsween 7y ago
Seccomp is a horrible security model for containers, if the application or it's libraries use differing syscalls the seccomp ruleset is invalid
- pbar 7y ago
  A process making a system call to the kernel functions the same way regardless of whether it is in a container or not. How exactly does the security model differ at all?
  - nwmcsween 7y ago
    Because 99.9% of software doesn't make use of direct syscalls, instead it uses wrappers or standard functions that wrap various other syscalls that can and will change over time. Meaning $app_container v0.1 can and probably will have a different seccomp filter than $app_container v0.2
    - pbar 7y ago
      This is the same case regardless of being in a container or not, $app v0.1 and $app v0.2 will have different filters
      - nwmcsween 7y ago
        Of course will but docker, et al attach filters to containers vs attaching it to a specific binary that is much easier (although still broken).
pbar 7y ago
You might find the Kubernetes offer interesting. Pod Security Policies[1] expose seccomp and selinux configuration in the form of annotations. [1]: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp https://kubernetes.io/docs/concepts/policy/pod-security-poli...

syrusakbary 7y ago

Since Wasmer is in control of all the syscalls its actually quite easy to manage the privileges in a more fine-grained way (think on CloudABI permissions on top of your containers)

anaphor 7y ago
That sounds really interesting. I'm going to check it out. Thanks for working on this!

nwmcsween 7y ago

Seccomp is a horrible security model for containers, if the application or it's libraries use differing syscalls the seccomp ruleset is invalid

pbar 7y ago
A process making a system call to the kernel functions the same way regardless of whether it is in a container or not. How exactly does the security model differ at all?
- nwmcsween 7y ago
  Because 99.9% of software doesn't make use of direct syscalls, instead it uses wrappers or standard functions that wrap various other syscalls that can and will change over time. Meaning $app_container v0.1 can and probably will have a different seccomp filter than $app_container v0.2
  - pbar 7y ago
    This is the same case regardless of being in a container or not, $app v0.1 and $app v0.2 will have different filters
    - nwmcsween 7y ago
      Of course will but docker, et al attach filters to containers vs attaching it to a specific binary that is much easier (although still broken).

pbar 7y ago

You might find the Kubernetes offer interesting. Pod Security Policies[1] expose seccomp and selinux configuration in the form of annotations. [1]: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp https://kubernetes.io/docs/concepts/policy/pod-security-poli...