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

["Kamil Rytarowski" <n54%gmx.com@localhost>]

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?