Bug 173285 - Insecure '--root' operations
Insecure '--root' operations
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
: Reopened, Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-15 17:26 EST by Enrico Scholz
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-03 05:56:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2005-11-15 17:26:42 EST
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%
Comment 1 Jeff Johnson 2005-11-15 18:19:59 EST
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 02:51:58 EST
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 11:43:53 EST
rpm with db4 is not appropriate to your vserver environment then.

Choose a different tool.
Comment 4 Axel Thimm 2006-08-07 07:49:30 EDT
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 10:55:58 EDT
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 15:02:32 EDT
Fixed (by opening all non-temporaray indices before
entering the chroot) in rpm cvs, will be in rpm-4.4.7 when released.

UPSTREAM
Comment 7 Panu Matilainen 2007-07-03 05:56:25 EDT
Should be fixed in 4.4.2.1 (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.