Bug 23195 - portmap runs with group root!
portmap runs with group root!
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: portmap (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Aaron Brown
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-02 18:35 EST by Chris Evans
Modified: 2007-04-18 12:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-28 18:41:48 EST
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 Chris Evans 2001-01-02 18:35:33 EST
I notice that portmap runs with the following credentials:
user "rpc"
group "root"

The user is great - the dubious "bin" user is no longer used.
But the group is a cause for concern, because I would be very unsurprised
to see group root lead to trivial full user root compromise (the occasional
dangerous thing is left writable by group root, separate bugs to be filed).

Can we please use a different group. Ideally a new group "rpc" (if it does
not
already exist). If that's too much hassle, something like "nobody" is a lot
better
than root!
Comment 1 Bill Nottingham 2001-01-03 12:18:27 EST
Fixed in portmap-4.0-30; just required a couple of setgid() before the
setuid().
Comment 2 Chris Evans 2001-02-06 11:52:32 EST
BETA 3: portmap correctly runs as group "rpc".
By the way, switching away from user "bin" running portmap was
a very cool move, because lots of binaries owned by user "bin"
could have led to easy root access.
Comment 3 Chris Evans 2001-02-25 09:40:42 EST
Argh!
Just noticed that portmap is running with a bunch of
supplementary groups, including the _extremely_
dangerous disk group.

This represents a severe regression since RH6.x,
because a portmapper hole may now be trivially
leveraged to a root shell.

Bill - probably just a missing initgroups() call - could
you nail this before RH7.1 release?
Comment 4 Trond Eivind Glomsrxd 2001-02-25 10:21:01 EST
I'll fix it.
Comment 5 Trond Eivind Glomsrxd 2001-02-27 01:17:21 EST
Hmm... how do you actually see it's a member of that group?

I get this from /proc/pid:



[root@xyzzy2 607]# cat status
Name:
portmap
State:
S (sleeping)
Pid:
607
PPid:
1
TracerPid:
0
Uid:
32
32
32
32
Gid:
32
32
32
32
FDSize:
32
Groups:

VmSize:
    1484 kB
VmLck:
       0 kB
VmRSS:
     576 kB
VmData:
      44 kB
VmStk:
      12 kB
VmExe:
      28 kB
VmLib:
    1360 kB
SigPnd:
0000000000000000
SigBlk:
0000000000000000
SigIgn:
8000000000011000
SigCgt:
0000000000000002
CapInh:
0000000000000000
CapPrm:
0000000000000000
CapEff:
0000000000000000
[root@xyzzy2 607]

(32 being the rpmc group)
Comment 6 Trond Eivind Glomsrxd 2001-02-28 18:41:44 EST
Ah. It doesn't happen by default, only if you restart it in a root login shell -
it inherits the groups.
Comment 7 Trond Eivind Glomsrxd 2001-02-28 19:24:17 EST
Fixed in portmap-4.0-35, which you can find at http://people.redhat.com/teg/

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