Description of problem: When using '--root' rpm accesses the rpmdb directly without doing a previous 'chroot(2)'. This breaks functionality and opens attack vectors. E.g. a malicious user with root rights in the chroot could do a 'ln -s /var/lib/rpm /var/lib/rpm' and next 'rpm' operation on the host would access the host rpmdb. Example: | # d=/tmp/rpmtest | # rm -rf $d | # mkdir -p $d/var/lib | # ln -s /var/lib/rpm $d/var/lib/rpm | | # rpm --root $d -q rpm | rpm-4.4.1-22 | | # rm -f $d/var/lib/rpm | # ln -s /etc/nologin $d/var/lib/rpm/__db.002 | # rpm --root $d -q rpm | $ ssh londo | | Connection closed by 192.168.46.6 strace shows at the last command things like | stat64("/tmp/", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=340, ...}) = 0 | stat64("/tmp/rpmtest/", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/tmp/rpmtest/var/", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/tmp/rpmtest/var/lib/", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/tmp/rpmtest/var/lib/rpm", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 | access("/tmp/rpmtest/var/lib/rpm", W_OK) = 0 | access("/tmp/rpmtest/var/lib/rpm/__db.001", F_OK) = 0 These operations should be executed after a previous 'chroot("/tmp/rpmtest")' (or the directories must be changed in a secure manner (but this is much more complicated than a chroot)) '-U' operations are accessing the root rpmdb too: | # strace rpm -U setup-2.5.44-1.noarch.rpm --root $d | open("/tmp/rpmtest/var/lib/rpm/Conflictname", O_RDONLY|O_LARGEFILE) = 6 | fcntl64(6, F_SETFD, FD_CLOEXEC) = 0 | fstat64(6, {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0 | rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0 | rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 | umask(022) = 022 | open("/var/lib/rpm/__db.000", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 7 Version-Release number of selected component (if applicable): rpm-4.4.1-22 How reproducible: 100%
A "malicious user with root rights" can get out of a chroot much more easily than through rpm vectors by doing fchdir("..)". Reducing the "Danger Will Robinson!!!!" security level to normal.
Wrong; there are existing secure chroots. E.g. look at http://linux-vserver.org; the current behavior is a real security risk there.
rpm with db4 is not appropriate to your vserver environment then. Choose a different tool.
I think this is a real security risk, too. It's very much unlike breaking out of chroots as the risk is there even if chroot-breaking-out would be prohibited otherwise (e.g. selinux or a even a pure non-root fakechroot environment).
The answer is the same: rpm with db4 is not the right tool if trying to use vserver's "secure chroots" and --root. Copy packages into the chroot, and run rpm only from within the chroot is one fix. Using sqlite3 is another.
Fixed (by opening all non-temporaray indices before entering the chroot) in rpm cvs, will be in rpm-4.4.7 when released. UPSTREAM
Should be fixed in 4.4.2.1 (rc) as well, similarly as in 4.4.7