[Rpm-maint] The current -root functionality (enter chroot and jump out of it) is unportable and utilizes security holes

Kamil Rytarowski n54 at gmx.com
Sun Aug 18 16:31:19 UTC 2013


I experienced, a few months ago, problems with the 'rpm --root' functionality. It simply enters the chroot() do what it is supposed to do inside it (manage packages, install new one etc) and... using a security known and old vulnerability jumps out of it.

This is welcome in the vanilla Linux kernels, but it's deliberately blocked in enhanced kernels -- most notably those using grsecurity [1].

Enhanced Linux kernels restrict possibilities to exit chroot() reducing privileges or internal functionality to software. The BSD kernel are also *be default* secured. The result is that the --root feature is broken.

I was trying to reimplement it through fork() and then chroot(), killing the chroot() session with _exit() -- but it was also broken, because managing RPM packages utilizes more dangerous for security reasons features (e.g. running mknod, managing special privilege and more [2]) -- and in the end I wasn't able to build chroots without lowering security levels in the system.

Wikipedia [3] says on the grsecurity enhancements pointing out what it's forbidden to do:

Chroot Modifications:
No attaching shared memory outside of chroot
No kill outside of chroot
No ptrace outside of chroot (architecture independent)
No capget outside of chroot
No setpgid outside of chroot
No getpgid outside of chroot
No getsid outside of chroot
No sending of signals by fcntl outside of chroot
No viewing of any process outside of chroot, even if /proc is mounted
No mounting or remounting
No pivot_root
No double chroot
No fchdir out of chroot
Enforced chdir("/") upon chroot
No (f)chmod +s
No mknod
No sysctl writes
No raising of scheduler priority
No connecting to abstract unix domain sockets outside of chroot
Removal of harmful privileges via cap

I haven't been investigating the enhancements of other Unices and Unix-like systems. I don't know if there is any Unix(-like) system, except Linux, without enhancements here. I don't want to even evaluate 'holes' in the OpenBSD systems...

My conclusion was clear -- the only way to implement -root in a portable way is to abandon the idea of chroot() at all, and reimplement it in other way. Unfortunately, until I miss some other way, it looks difficult, because involves changes in the whole code-base adding to it functionality that says 'Am I in chroot?'.

This functionality is key important, because it allows to build packages in chroots and install system from RPM packages -- so in other words it allows to manage Unix system outside installed RPM package.

We provide calls in our API for entering and quiting (!) from chroot -- as it shall not be broken, there could be preserved the same naming of it, but implemented in the right way. Making it portable will make RPM a tool to manage real systems, other than security unenhanced Linuxes, in wider space then just installing single package delivered by a vendor.

Please, what do you think? How would we solve it? Do you propose a way to reimplement the current code-base? I can do it - as soon as I will be back home, but it now requires open discussion -- as the remind walk-around with fork() isn't solution.

Kamil Rytarowski

[1] http://grsecurity.net/
[2] http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Chroot_jail_restrictions
[3] http://en.wikipedia.org/wiki/Grsecurity
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20130818/92fa7309/attachment.html>

More information about the Rpm-maint mailing list