Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The chroot Technique – a Swiss army multitool for Linux systems

livesys.se

Post reply on HN
Print view View original

111–120 of 123 posts

Re: The chroot Technique – a Swiss army multitool for Linux systems

#111

Post by amelius »

ndsipa_pomu wrote: post #109
amelius wrote: post #107

What if I'm ssh'd into a Linux box and want to (say) format its root disk. Can I boot a new instance of Linux in memory and then access the root disk?

Interesting question and I don't know how you'd do that - maybe using some statically linked binaries for fdisk and mkfs. However, why would you ever want to do that? If you want to remove data from the disk, then just running a suitable "dd" command would wipe the disk. I can't think of any other use case that wouldn't subsequently involve booting from a live iso which would let you format the disk anyway.

One use case is: what if the computer is at a remote location and you'd want to put a new image on the main disk. If Linux is currently using that disk as its root disk, then I suppose you'd have to somehow unmount it, or use a different instance of Linux that runs entirely in ram (so you can kill the original Linux instance and overwrite it).

Re: The chroot Technique – a Swiss army multitool for Linux systems

#112

Post by ndsipa_pomu »

amelius wrote: post #111
ndsipa_pomu wrote: post #109

Earlier quoted context omitted.

Interesting question and I don't know how you'd do that - maybe using some statically linked binaries for fdisk and mkfs. However, why would you ever want to do that? If you want to remove data from the disk, then just running a suitable "dd" command would wipe the disk. I can't think of any other use case that wouldn't subsequently involve booting from a live iso which would let you format the disk anyway.

One use case is: what if the computer is at a remote location and you'd want to put a new image on the main disk. If Linux is currently using that disk as its root disk, then I suppose you'd have to somehow unmount it, or use a different instance of Linux that runs entirely in ram (so you can kill the original Linux instance and overwrite it).

I guess you could boot into a live installer ISO and get that to install over the root disk, though I don't know what problems you'd face with trying to unmount the original root partition.

If you're wanting to do something like that fairly regularly, then it'd be easier to just run virtual machines (e.g. QEMU/KVM) to do that kind of thing.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#113

Post by amy214 »

dicroce wrote: post #4

I actually wish that instead of docker & etc we had just gotten a better chroot... Or maybe just a new kernel syscall that is chroot()++.

We should get a better change root yes, and the LD_LIBRARY_PATH gets autoupdated with respect to the new root. A few flags here and there to set permissions of the child process and we're off too the races.

Oh wow, wow. That all sounded so intensely complex, incomprehensible. What we are going to need to do is build a program to handle all that, highly formalized. Let's make it so formalized it's one of those things like taxes or AWS where people can just make a living from understanding the beast. It can be like systemd meets multics meets java. have it's own various complicated commands, complicated file formats, and so on. The chroot() is only historically understood by everyone, so let's steal a page from the java playbook and just rename everything with our own terminology. The product will be so outstanding, wow, I call it "Shocker"

Re: The chroot Technique – a Swiss army multitool for Linux systems

#114

Post by Cu3PO42 »

amelius wrote: post #107

What if I'm ssh'd into a Linux box and want to (say) format its root disk. Can I boot a new instance of Linux in memory and then access the root disk?

It's definitely possible. nixos-anywhere [0] implements this in a neat package for NixOS specifically. I am relatively certain you could use the same script to boot into a different distribution, though the installation part itself would obviously need to be adapted.

[0] https://github.com/nix-community/nixos-anywhere

Re: The chroot Technique – a Swiss army multitool for Linux systems

#115

Post by jeroenhd »

thatcherc wrote: post #67
seba_dos1 wrote: post #3

With qemu-user and binfmt you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC to fix a hacking session gone wrong. Though these days you may want to look into things like systemd-nspawn instead of plain chroot.

> you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC This sounds very interesting! What's the scenario where you'd do this? Would you be, for example, emulating an ARM processor with qemu on an x86 computer and chrooting into Android on an eMMC?

chroot can be a alternative to setting up fussy cross-compilers. It'll be slower, but that slowness pays off as long as you spend less time on extra CPU cycles than you do on getting cross compilers to work.

It's also useful for reverse-engineering router/IoT firmware.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#116

Post by foresto »

alfiedotwtf wrote: post #105
foresto wrote: post #58

Earlier quoted context omitted.

> There seems to be a fundamental mismatch between how sane people think about sandboxing, and how linux manages namespaces. What bothers me most about sandboxing with linux namespaces is that edge cases keep turning up that allow them to trick the kernel into granting more privileges than it should. I wonder if Landlock can/will bring something more like FreeBSD jails to the table. (I haven't made time to read about…

This is why I would still rather isolate using QEMU, docker, or Virtually Box rather than a very think chroot-like environment

Docker uses namespaces by default. Are you using an add-on that makes it use a hypervisor instead?

Re: The chroot Technique – a Swiss army multitool for Linux systems

#117

Post by vacuity »

rootnod3 wrote: post #33
alphazard wrote: post #25

Earlier quoted context omitted.

There seems to be a fundamental mismatch between how sane people think about sandboxing, and how linux manages namespaces. A linux-naive developer would expect to spawn a new process from a payload with access to nothing. It can't see other processes, it has a read only root with nothing in it, there are no network devices, no users, etc. Then they would expect to read documentation to learn how to add things to the…

That is pretty much what jails are in FreeBSD, especially thin jails.

Or capabilities. Additive security has been known for decades; Linux really dropped the ball here. Linux file descriptors (open file descriptions, whatever) are close to a genuine capability model, except there's plenty of leakage where you can get at the insecure base.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#118

Post by vacuity »

immibis wrote: post #84
sgt wrote: post #56

Earlier quoted context omitted.

Not really, but yes there's a lot of files or things that seem to be files. Try plan9 though.

If you want to blow your mind in what's possible in operating-system isolation read about KeyKOS from 1985: https://css.csail.mit.edu/6.858/2014/readings/keykos.pdf Such systems are rarely very pragmatic, but do show off a bunch of weird concepts.

Definitely weird, or perhaps I'm just not imaginative enough. I have a hard time figuring out what some KeyKOS constructs mean in familiar terms, particularly whether a given feature is an instance of essential or accidental complexity. I'm more familiar with today's seL4, which has carried on many of the principles of KeyKOS. Learning about the state of the art today is one thing, but learning history is quite another. I rely on simplicity in kernel design to avoid hindering more creative ideas that others have had.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#119

Post by out-of-ideas »

mystified5016 wrote: post #11
smallpipe wrote: post #2

The arch linux install has a little wrapper around chroot, used to configure the installed system without booting it. https://wiki.archlinux.org/title/Installation_guide#Chroot

Manjaro has the same, I'd assume inherited from arch and modified. I just wish the script could figure out a BTRFS drive without me manually mounting volumes :(

i was very happy when that arch-chroot + pacstrap simplified my arch setup not having to run those mounts (i remember doin the same setup process for arch for centos/rhel just to not use anaconda and removing bloat, or rather installing what i wanted)

for btrfs, if you use a consistent volume mapping on your systems, its pretty easy. in arch setup i typically enable ssh and have a pretty simple set of bashisms for target device, compression, and mount points. then its copy-pasta since its a boiler plate for when i need to recover or fresh install

not glanced at manjaro so not familiar with its install-methods

Re: The chroot Technique – a Swiss army multitool for Linux systems

#120

Post by ranger_danger »

fsniper wrote: post #104
benou wrote: post #74

Earlier quoted context omitted.

Here is an example of preparing a debian ARM image on x86 with debootstrap, qemu and chroot: ~# sudo apt install qemu-user-static debootstrap ~# mkdir /tmp/arm ~# debootstrap --foreign --arch=armhf buster /tmp/arm http://deb.debian.org/debian ~# cp /usr/bin/qemu-arm-static /tmp/arm/usr/bin/ ~# chroot /tmp/arm # from that point, you're running ARM! ~# /debootstrap/debootstrap --second-stage

This is very cool! I had no idea you could chroot into different architectures.

Well technically you can't, in the sense that chroot has no idea you're doing it... the magic of binfmt support in the kernel (setup for qemu by the post-install script for qemu-user-static I believe) basically lets you run any architecture's binary that qemu-user-* supports just by trying to execute it natively, it basically just translates the execution of "./other-arch-cmd" into "qemu-user-static ./other-arch-cmd".
Post reply on HN