Show HN: Avenv – A more isolated virtualenv
github.com
github.com
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.
What in this world isn't beta?
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.
But aren't we all a little beta anyway?
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)
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.
> > 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!
$ venv/bin/xbps-install -Sy libreoffice xorg-fonts # you can imagine that as kind of like a chrooted void linux
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
> Linux only support
>
> Tell your employer to stop using Macintosh
... because that doesn’t seem like a sign of a serious project to me...