Re: Relax the prohibition of usage fchdir(2) to quit a chroot

Hello all,

Thank you for your answers.

Please let me be more explicit in my use-case. There are two common types of environment when [rpm] --root is used:
1. a system installer,
2. a build machine.

An installer/builder creates a certain directory, say: /mnt/chroot. Then it takes packages one after another from say /mnt/arsenal. It untarballs one file after another, (say ammo1.pkg, ammo2.pkg, ammo3.pkg) files and then chroots(2) inside /mnt/chroot to run scriptlets embedded in the .pkg files, with scripts for say postinst procedure. After finishing the scriptlets it quits /mnt/chroot and takes next file doing the same.


There are two primary design issues with it.

The first design issue is with quitting the chroot environment. It's walk-aroundable with e.g. fork(2) and letting the subprocess die after doing its job.

The second one more several is letting a subprocess to do nasty things, that shall be forbidden in a secured environment, most notably is playing with mknod(8).


Now please assume that ammo1.pkg embeds (as a /bin/sh script): mknod /dev/console -and-some-standard-parameters-here

And now using fork(2) to go inside the chroot environment and then use mknod gives head-ache. Solving it with grabbing scriptlets and piping commands to execute by the master process introduces problems with path translation, and here are comes non-trivial use-cases... analyzing them is left for a reader. Trying to solve this with grabbing syscalls of the child and translating paths is non-trivial.. etc. (I need to do it natively, without fakechroot).

Well back to the problem. I'm strongly for enforcing all possible chroot restrictions... but letting a "backdoor" (disabling the restrictions) on demand. There is a general design issue that gives a head-ache -- I would whisper a Unix design issue -- but actually this hack does the job very well and it's deployed in number of Unix-like systems around.

All chroot restrictions are swappable in runtime with grsecurity on the Linux platform.

BTW. LKM solution seems interesting, but how could it work?