Unfortunate name choice. There's already a Plash [1,2] project for the Principle Least Authority Shell.
Show HN: Plash – Build and run containers
21–30 of 31 posts
Re: Show HN: Plash – Build and run containers
#22Really cool, I like the documentation on the website - would be nice if the README was actual HTML though. Does that mean I can build container images within a running container (for example the GitLab-CI) without doing a stunt like docker-in-docker or fakechroot/fakeroot? What are you using instead of fakeroot? I've seen people like [zwischenzugs][0] using User Namespaces - which makes it impossible to be run within…
Thank you :-) > Does that mean I can build container images within a running container (for example the GitLab-CI) without doing a stunt like docker-in-docker or fakechroot/fakeroot? Sure, plash's unit tests involve building and they run inside a plash instance at travis CI. I'll have lunch now and then continue with the reply after.
I think you can already build Docker images via Docker within travis CI, because they somehow provide you (semi?-)privileged access to the required Linux cgroup and namespace features.
If you are running within a regular Docker container commands such as
sysctl -w kernel.unprivileged_userns_clone=1
Am I doing something wrong?
Re: Show HN: Plash – Build and run containers
#23Really cool, I like the documentation on the website - would be nice if the README was actual HTML though. Does that mean I can build container images within a running container (for example the GitLab-CI) without doing a stunt like docker-in-docker or fakechroot/fakeroot? What are you using instead of fakeroot? I've seen people like [zwischenzugs][0] using User Namespaces - which makes it impossible to be run within…
Thank you :-) > Does that mean I can build container images within a running container (for example the GitLab-CI) without doing a stunt like docker-in-docker or fakechroot/fakeroot? Sure, plash's unit tests involve building and they run inside a plash instance at travis CI. I'll have lunch now and then continue with the reply after.
To continue the reply...
plash uses along others linux namespaces and chroot. So inside a linux namespace you can actually use the vanilla chroot:
ihucos@macbook:~/plash$ # get an example rootfs
ihucos@macbook:~/plash$ mkdir /tmp/m
ihucos@macbook:~/plash$ plash mount --from ubuntu -- /tmp/m
ihucos@macbook:~/plash$
ihucos@macbook:~/plash$ unshare --map-root --user --mount
root@macbook:~/plash# chroot /tmp/m
root@macbook:/# type apt
apt is /usr/bin/apt
root@macbook:/# exit
Interesting topic. I wanted to, but did not come very far. Maybe now that I "finished" plash and have more time haha.
btw: I just tested and you can just run unprivileged plash containers inside a unprivileged plash process! But you need to install unionfs-fuse in the first container. When/If I port plash to C maybe that dependency can be statically linked or something like that, lets see.
> Really cool, I like the documentation on the website - would be nice if the README was actual HTML though.
Thanks, the README is not in markup so it's one little dependency less when I have to migrate out from Github at some point (M$)
EDIT:
> Edit: Why the downvote? Am I misunderstanding something?
It wasn't me, I think they where great questions!
Re: Show HN: Plash – Build and run containers
#24Earlier quoted context omitted.
Thank you :-) > Does that mean I can build container images within a running container (for example the GitLab-CI) without doing a stunt like docker-in-docker or fakechroot/fakeroot? Sure, plash's unit tests involve building and they run inside a plash instance at travis CI. I'll have lunch now and then continue with the reply after.
I think you can already build Docker images via Docker within travis CI, because they somehow provide you (semi?-)privileged access to the required Linux cgroup and namespace features. If you are running within a regular Docker container commands such as sysctl -w kernel.unprivileged_userns_clone=1 are not possible, due to /sys being read-only. Am I doing something wrong?
> I think you can already build Docker images via Docker within travis CI, [...]
The nice think about plash is that you don't have to worry about "official" support.
> [...] due to /sys being read-only.
Dammit, no, so yeah, apparently unfortunately for regular docker containers (not privileged ones) you need to disable unsharing in plash (export PLASH_NO_UNSHARE=1). In that case the only requirements are chroot, a rudimentary mount binary and overlay OR unionfs-fuse and root access. So it should even run in BSD/Minix/macOS and stuff like that, BUT the mountpoints will not get cleaned up. For an instance running for a while that would be a problem, for a temporary docker container not.
Re: Show HN: Plash – Build and run containers
#25I 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 operati…
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…
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".
Re: Show HN: Plash – Build and run containers
#26Any reason for not using markdown in your README? Not rendering well on my phone at all.
Re: Show HN: Plash – Build and run containers
#27Earlier quoted context omitted.
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…
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".
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.
Re: Show HN: Plash – Build and run containers
#28Any reason for not using markdown in your README? Not rendering well on my phone at all.
Not particular strong ones. I actually imagined that .txt is more accessible, maybe the wrapping must be tighter. I like it because its very WYSIWYG. The UTF-8 art looks better there than in a code block. And it's one little dependency less, if for example at some point development should migrate to another platform.
Re: Show HN: Plash – Build and run containers
#29Earlier quoted context omitted.
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".
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 conta…
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?
Re: Show HN: Plash – Build and run containers
#30Earlier quoted context omitted.
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 conta…
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?
Maybe let me try something like this:
Thread Plash is conceptually somewhere between containers as they existed until now and operating system processes. Technically a plash container is just a process. Security wise exactly the same rules that apply for UNIX processes, apply for plash containers. Which is why I say that they are much more secure than the stuff that major container systems have to do to create that extra layer of - buzzword alarm - isolation.
So whatever which term means what, the security concept of plash is really easy to understand: a plash container is just a process. You started plash with your user PinaColada - great, your plash container has PinaColada access rights, if it wants it can delete your PinaColad's home folder, but not system folders.
You want to create and AppArmor for a plash container like you could also do it with other processes? That would work.
You really like bubblewrap? wrap plash with it (not tried, but should work)
Virtually everything you can do with processes, you can do with plash.