5 ms·

I'd like to say good things, but there are a few big issues first. It goes to the effort of downloading the sha256 hashes... For a filename. It never actually

by shakna 8y ago

I'd like to say good things, but there are a few big issues first. It goes to the effort of downloading the sha256 hashes... For a filename. It never actually confirms a download is accurate with them. (curl --fail is not enough. You can have connections close nicely, but the file not be transferred correctly.) It depends on bchroot for the heavy lifting, which is a beta product still, though interesting, and your own... And the habit of placing binaries in git do give me some twinges of concern. It would take more time than I have to audit bchroot. I have some concerns about binding /tmp and /dev the way you do... But a bigger concern is the assumption that /bin/bash will be available. What if it isn't? It copies _my_ resolv.conf into the chroot blindly, despite the fact that many network managers may overwrite this file, and that my computer can move between networks where this may change. It'd be better to at least symlink the file. Best would be running a network manager. It assumes x86_64. Reasonable-ish, but not always accurate. A Raspberry Pi is just as strong a target. Use uname -m. You'll probably hit issues otherwise. Speaking of which, if you feel the need to grab resolv, you probably want hosts as well. avenv-update finds and sorts binaries from a few static locations. It'd be much better if it could rely on a PATH variable. --- As a _first_ chroot manager attempt, it's not awful. You set the right failure flags for sh, and handle most of the fail conditions nicely. ... But never trust the internet to hand you blindly what you ask for. ... And never trust the assumptions you've made about what it's running on will also be accurate.

fiatjaf 8y ago
> It depends on bchroot for the heavy lifting, which is a beta product still What in this world isn't beta?
- shakna 8y ago
  Most of the common chroot tools? Like arch-chroot? Depending on your own tool is fine, but it does mean you don't have a team of people ensuring that security holes are plugged. Means, in this case, the attack surface isn't just avenv, it's avenv + bchroot.
  - ihucos 8y ago
    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?
ihucos 8y ago
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)
- shakna 8y ago
  > 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.
  - ihucos 8y ago

by shakna 8y ago

fiatjaf 8y ago

> It depends on bchroot for the heavy lifting, which is a beta product still What in this world isn't beta?

shakna 8y ago
Most of the common chroot tools? Like arch-chroot? Depending on your own tool is fine, but it does mean you don't have a team of people ensuring that security holes are plugged. Means, in this case, the attack surface isn't just avenv, it's avenv + bchroot.
- ihucos 8y ago
  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?

ihucos 8y ago

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)

shakna 8y ago
> 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.
- ihucos 8y ago