ihucos

That's interesting. Here in Berlin there is/was also a restaurant where you could pay what you want when you leave and it seemed to also work there. I can imagine important is to explicitly state that you do have costs and are expecting payment - it's just not such a strict thing and if you are a student of course you pay less. Let's see how it goes.

Also see here: https://github.com/ihucos/counter.dev#how-can-it-be-free

Ahh the request is only done for unique users - so if you already was there once he won't send another request again until you clear your browsing data (or just the sessionStorage)

Hmm it worked for me on my Chrome. It might be a plugin you have? Not sure.

Yes, thank you! Fixed and deployed.

> [...] but your job is more valuable!

Well, not if I spend my free time on open source projects :-D

I am doing this together with my regular job. At the very moment it does cost me about the same as the Netflix account I am paying for my parents. The plan to be profitable is by mass. There was a lot of time and thought spend on making this service really really cheap to serve. Even now with this HN my redis database is two megabytes in size and before this HN post with happy and active users the CPU did not went over 1% usage - on a cheap VPS. So the bottom line is if we can get in only a small fraction of what other services have as a fee I am happy. I think we are talking about less than one cent per user per month. In any case I feel comfortable to get that with Pay as you want and one advertising banner. Don't get me wrong. It is a great product and we do expect users to actually pay for it if they are using it on a commercial project. We just have the luxury to ask for a payment instead of charging it. I also think plausible is a great product. If you are happy with it even better :-)

Thanks for writing. There was absolutely no activity done on that twitter account. In any case we swapped it to one that is actually active :-) https://twitter.com/NaiveTeamHQ

Yes, so although it is optimized to be very cheap to operate many users there still are costs. We hope to get that via donations or as it's communicated in the website "Pay what you want". One single advertising banner is also something we are considering. So the amount we have to get from active users is really low. Currently there are 80 integrations with multiple sites on the cheapest linode VPS. The redis database is 2 megabytes on disk and the CPU does not go over 1% usage (before this HN post). If you just take our current integrations and divide them by the costs the VPS makes you get to pennies per user per month. I did not put in my calculation that not all integrations are active but you get the idea :-)

Thanks! That is really cool to hear.

At the first sight they really look quite similar. Counter does not use a relational database and is highly optimized to serve users for free. If you want more details and really dig into the data plausible could be a better fit. If you value a free product and don't need too much details or actually even value less data collection then I would say go with counter.

That's why with counter you can get started in like 10 seconds. And permanently delete your data via the GUI if you don't like it :-)

Thank you very much! Fixed, will be visible once caches are expired.

Why TTY in the name, exit codes are returned by processes, regardless if they opened a TTY or not.

For my personal project (http://plash.io/) I try to archive something similar by:

* Only use technology that already exists for at least 10 years and is widely used: bash python3 C and Linux

* No external libraries, only the python standard library and the C standard library

* No monolithic design, it's a mix of about 30 standalone utilities that I can rewrite gradually if for example ever python3 becomes out of fashion.

* Keep the line count low

* Rely on proven abstractions like processes, files, pipes, the environment list, etc

Generally it could be possible to run single (bloated) applications inside a container. Here is the solution I wrote for Linux: http://zpkg.plash.io/

neither avenv nor bchroot (nor chroot by the way) claim any security gain. Bugs are in this case just bugs and I'll fix them. bchroot is ~ 200 lines C, avenv is 60 lines shell scripting. It's really no big deal.

But aren't we all a little beta anyway?

> > > I have some concerns about binding /tmp and /dev the way you do...

> > Can you elaborate what exactly the issues is? I use this quite often.

> It's a container escape. The chroot shouldn't be able to access the hosts tmp files. Creating a tmpfs and using that is a safer method. If you can read and write the hosts tmpfs, then you can impact the behaviour of the host.

ok ja, I know, I am also mounting /home. There are no guarantees that there is any security gain by using this and security is not the goal of this software.

> For /dev it's just because it has to be a proper bind, and I haven't looked deeply enough to check that happens.

I am using `mount("/dev", "./rootfs/dev", "none", MS_MGC_VAL|MS_BIND|MS_REC, NULL)` so a recursive bind so we also get stuff like "/dev/pts". I am using this regularly and it works perfect for me, let me know if you know of any specific problems with this!

The whole shell script is really just because it's a protoype (=Initial commit). If I get good feedback, I'll rewrite this in proper python code. At least for myself it's already good enough to use it.

The thing that worries me more is the bchroot.c, but since it does not promise any guarantees on isolation and is not setuid or so there really should'nt be any security issues.

> I have some concerns about binding /tmp and /dev the way you do...

Can you elaborate what exactly the issues is? I use this quite often.

> But a bigger concern is the assumption that /bin/bash will be available. What if it isn't?

Then you'll have to call 'bchroot ./rootfs /bin/ash' instead of just 'bchroot ./rootfs', just like with the regular chroot.

> It copies _my_ resolv.conf into the chroot blindly, [...]

bchroot mounts the hosts resolv.conf over it anyway. This is just a redunancy for some corner case I have (whole programming environment already inside an namespaced chroot)

To my haters: It's clearly a prototype. 60 lines of shell script will always have their own issues. What I'd love to hear is thoughts on the general approach! Is this cool enough to do proper?

This also works with others package managers/distributions. Only with apt/apt-get you need some extra configuration "APT::Sandbox::User=root"

I was thinking about using Ubuntu, but in the end took void linux because it's the smallest glibc based distribution I could found. Python wheels don't work on musl based distributions

check it out, there are some recipes now.

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.

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.

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.

> 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.

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

> Have you investigated into creating reproducible containers?

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!

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.

> 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)

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