Hacker News Reader

Comment by ihucos | Hacker News Reader

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

View on HN

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.

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 < Process < Plash < Container < Full virtualization < Dedicated Hardware

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.

Reply on news.ycombinator.com