chroot’s aren’t secure. Research “chroot escape”.
A lot more of that. I don’t think chroots were invented with security in
mind. I guess if chroot’s were secure, nobody would bother with VMs /
containers.
Maybe that’s why CLIP OS uses containers?
madaidan via Whonix Forum:
What if we install all user applications into a separate chroot?
User runs “sudo apt install pkg-name”. How to make install that to chroot?
Another stackable wrappers issue?
At least the initial implementation could surely live without “sudo apt
install pkg-name” replacement and this being an opt-in.
How to make install that to chroot? Maybe it shouldn’t?
Maybe after we have
user user can’t use APT anymore. Maybe after implementing that it
would be a good time to invent new commands such as apt-chroot?
So we have the base system image that’s verified with dm-verity.
Sounds like a lot development work since nobody publicly implemented
that with Debian yet or any Linux desktop distribution.
He has some examples that don’t look too difficult for non-encrypted
(VM) setups.
But then integrating that into the build process is non-trivial.
Also how would we upgrade the base system image?
Whenever the user executes their app it chroots and executes it.
Every app the same chroot or different chroots? Could be same chroot but
home folder isolation? And yet a way to share files among apps through
shared folders? Similar to android?
sudo chroot /apps $program
That would execute the program as root. Even if chroot, we ought to run
as little as possible as root.
The only issue with this is all the directories are mounted read-write so any modification to e.g.
/apps/binwould modify/bintoo. There should be a way to mount the base system as read-only but the everything else in the chroot as read-write.
Qubes TemplateBasedAppVMs can write to the shared root image (including
/usr/bin etc.) of TemplateVM but these changes aren’t actually written
to actual TemplateVM root image. These are written to volatile.img and
discarded after shutdown. However, all applications can write to the
root image. They won’t “notice” anything. Similar to a Live ISO overlayfs?