6 ms·

I find the first item in the README a bit misleading: Security: plash containers run completely unprivileged. What this actually means is that plash conta

I find the first item in the README a bit misleading: Security: plash containers run completely unprivileged. What this actually means is that plash containers run as the current user, so not as root. But they provide no isolation whatsoever, which I would expect from containers (and which Docker provides, to a certain extent). The README does mention this, but only much later: - Plash processes have the same operating system access rights than the process that started it. There is no security relevant isolation feature. Exactly as with running programs "normally", don't run programs you do not trust with plash and try to avoid using plash with the root user. rootless containers are still a little ways off it seems...

bthornbury 8y ago
https://github.com/projectatomic/bubblewrap https://github.com/projectatomic/bubblewrap This is the most promising one I've seen.
- austinjp 8y ago
  I'm unclear on their readme. Right at the bottom, they seem to suggest that once runC implements rootless containers, it will be a superior solution since it conforms to the Open Containers Initiative. Checking runC's GitHub, they merged a rootless container branch into their master branch a year ago. A related blog post says it's now inside Docker so very well used. So does Docker now provide containers that can guarantee immunity from (certain) privilege escalation attacks? Would you move to Docker/runC?
  - ihucos 8y ago
    > So does Docker now provide containers that can guarantee immunity from (certain) privilege escalation attacks? In my opinion the isolation mechanism of major container software like docker is flawed and thinking about it gives me headaches. One problem is that you need a daemon running as root. It's better if you don't have to leave the user space at all. To be fair plash relies on fuse and newuidmap/newgidmap which are suid, so there is at least a little bit happening with root access rights. But it's comparably very little and there is nothing self-baked running as root. There are many details that for me are unclear in docker, one out of the of the tip of my head, is that the usage of a overlay mount is disabled by non-root users (also inside user maps) because the kernel does not want to guarantee that a bogus setup can cause a security issue. > Would you move to Docker/runC? Never :-) The whole point of this is to not use Docker/runC. One of the core aspects of plash is that containers should just be normal processes. Processes is an interface that existed since decades, for containers I need to learn a new tool just to kill one or list all that are running (use ps/kill in plash)
- jquery_dev 8y ago
  That's what opam (ocaml package manager) uses for linux sandboxing
ihucos 8y ago
Oh boy, I am since one hour thinking about how to formulate it so its really crystal clear, maybe someone have a suggestion. In my head isolation and containerization are two completely different problems. If you really want "complete" isolation in plash you'd just had to setuid/setgid/setgroups away from the namespaced root user. Then as far as the kernel is concerned you would be a different user and if you are the only process with this uid you are completely isolated. Maybe I'll add an flag for that. EDIT: I am not happy with it at all but changed it: - Security: Traditional per user isolation. Containers run completely unprivileged. Containerisation and sandboxing are two different things. Sandboxing in major container software is fundamentally broken !111
- ofrzeta 8y ago
  So for you isolation and sandboxing are the same but both are different from containers? What's the function of containers then? Also I don't quite understand how you claim isolation/sandboxing but also offer "natural interaction with the host operating system".
  - ihucos 8y ago
    Yeah I don't know, the terms a a little mixed up. For me isolation and sandboxing is not the same. A function of a container is to provide a more well defined environment, usually for other application to run more reliable. That by itself says nothing about security. My claim of "natural interaction with the host operating system" is archived by just having containers being "normal" processes. You can see plash containers with top, kill them with `kill`, or set them a different nice value. They also have automagically environment variables like DISPLAY exported to them, so most graphical interfaces will work (you can e.G. run gimp or firefox). I did not invent any new sandboxing/security-related-isolation mechanisms. Since it's just processes, the usual rules for processes apply, like that you can't kill a process from another user, access rights for the filesystem are enforced and so on.
    - mbreese 8y ago
      So (for you) containers are more about not polluting the host OS and application configuration, rather than how you define how it works with the host OS? What about the difference between isolation and sandboxing? Isolation is keeping processes from interfering with each other, and sandboxing is keeping processes from interfering with the host OS? Something like that?

bthornbury 8y ago

https://github.com/projectatomic/bubblewrap https://github.com/projectatomic/bubblewrap This is the most promising one I've seen.

austinjp 8y ago
I'm unclear on their readme. Right at the bottom, they seem to suggest that once runC implements rootless containers, it will be a superior solution since it conforms to the Open Containers Initiative. Checking runC's GitHub, they merged a rootless container branch into their master branch a year ago. A related blog post says it's now inside Docker so very well used. So does Docker now provide containers that can guarantee immunity from (certain) privilege escalation attacks? Would you move to Docker/runC?
- ihucos 8y ago
  > So does Docker now provide containers that can guarantee immunity from (certain) privilege escalation attacks? In my opinion the isolation mechanism of major container software like docker is flawed and thinking about it gives me headaches. One problem is that you need a daemon running as root. It's better if you don't have to leave the user space at all. To be fair plash relies on fuse and newuidmap/newgidmap which are suid, so there is at least a little bit happening with root access rights. But it's comparably very little and there is nothing self-baked running as root. There are many details that for me are unclear in docker, one out of the of the tip of my head, is that the usage of a overlay mount is disabled by non-root users (also inside user maps) because the kernel does not want to guarantee that a bogus setup can cause a security issue. > Would you move to Docker/runC? Never :-) The whole point of this is to not use Docker/runC. One of the core aspects of plash is that containers should just be normal processes. Processes is an interface that existed since decades, for containers I need to learn a new tool just to kill one or list all that are running (use ps/kill in plash)
jquery_dev 8y ago
That's what opam (ocaml package manager) uses for linux sandboxing

ihucos 8y ago

Oh boy, I am since one hour thinking about how to formulate it so its really crystal clear, maybe someone have a suggestion. In my head isolation and containerization are two completely different problems. If you really want "complete" isolation in plash you'd just had to setuid/setgid/setgroups away from the namespaced root user. Then as far as the kernel is concerned you would be a different user and if you are the only process with this uid you are completely isolated. Maybe I'll add an flag for that. EDIT: I am not happy with it at all but changed it: - Security: Traditional per user isolation. Containers run completely unprivileged. Containerisation and sandboxing are two different things. Sandboxing in major container software is fundamentally broken !111

ofrzeta 8y ago
So for you isolation and sandboxing are the same but both are different from containers? What's the function of containers then? Also I don't quite understand how you claim isolation/sandboxing but also offer "natural interaction with the host operating system".
- ihucos 8y ago
  Yeah I don't know, the terms a a little mixed up. For me isolation and sandboxing is not the same. A function of a container is to provide a more well defined environment, usually for other application to run more reliable. That by itself says nothing about security. My claim of "natural interaction with the host operating system" is archived by just having containers being "normal" processes. You can see plash containers with top, kill them with `kill`, or set them a different nice value. They also have automagically environment variables like DISPLAY exported to them, so most graphical interfaces will work (you can e.G. run gimp or firefox). I did not invent any new sandboxing/security-related-isolation mechanisms. Since it's just processes, the usual rules for processes apply, like that you can't kill a process from another user, access rights for the filesystem are enforced and so on.
  - mbreese 8y ago
    So (for you) containers are more about not polluting the host OS and application configuration, rather than how you define how it works with the host OS? What about the difference between isolation and sandboxing? Isolation is keeping processes from interfering with each other, and sandboxing is keeping processes from interfering with the host OS? Something like that?