Comment by ihucos | Hacker News Reader

Comment by ihucos | Hacker News Reader

Parent Full thread

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)

> If I get good feedback, I'll rewrite this in proper python code.

I don't mind it being a shell script. So is arch-chroot, which is an amazing little tool.

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

The cheap way would be making a directory in /var/shm and symlinking to it.

The better way is creating a ramfs and mounting it.

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

> bchroot mounts the hosts resolv.conf over it anyway.

I'll still wait til you fix that symlink problem you've noted in the source - my resolv is definitely a symlink.

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

/bin/sh is generally guaranteed to exist (more often than /bin/bash). That's all. (Though technically the path /bin/sh isn't guaranteed by POSIX. You're supposed to use /etc/passwd to find the shell.)

> At least for myself it's already good enough to use it.

The goal of all software, if it works for you, fantastic.

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

Reply on news.ycombinator.com