Bug 57392 - netkit-rsh rshd rexecd in.rshd in.rexecd chdir nfs setuid
Summary: netkit-rsh rshd rexecd in.rshd in.rexecd chdir nfs setuid
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rsh   
(Show other bugs)
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-12-11 16:05 UTC by Alex Muntada
Modified: 2015-03-05 01:09 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-24 12:03:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rshd patch: perform setuid before chdir (691 bytes, patch)
2001-12-11 16:56 UTC, Alex Muntada
no flags Details | Diff
rshd.c, rexecd.c: perform setuid before chdir (1.26 KB, patch)
2001-12-11 17:38 UTC, Alex Muntada
no flags Details | Diff

Description Alex Muntada 2001-12-11 16:05:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; SunOS 5.7 sun4u; Nav)

Description of problem:
in.rshd fails to change to user's home directory if it is mounted by
NFS because it performs chdir(2) syscall before setuid(2) and user
running in.rshd (i.e. root) becomes nobody in NFS mounts.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. "mount /home" by NFS from some other host.
2. "chmod o= /home/username" disabling access to user nobody (username
   should still have access to its own home).
3. "rsh -l username hostname" from a remote host.

Actual Results:  % pwd
/

Expected Results:  % pwd
/home/username

Additional info:

There's a work-around to solve this issue but it has some security
drawbacks: "chmod o+x /home/username" enables user nobody to perform
chdir(2) syscall before changing UID through setuid(2). Users may not
want everybody to be able to access its home directory.

The best approach would be to modify rshd.c to perform UID changes
before chdir(2), which should be performed while running as the user
(not root nor nobody).

I've tested the latest source RPM available on ftp.redhat.com
(rsh-0.17-5.src.rpm) and the issue is still working in all 7.x
redhat versions.

Comment 1 Alex Muntada 2001-12-11 16:56:22 UTC
Created attachment 40352 [details]
rshd patch: perform setuid before chdir

Comment 2 Alex Muntada 2001-12-11 17:35:25 UTC
The same issue appears in rexecd.c from the same package as rshd.c.

Comment 3 Alex Muntada 2001-12-11 17:38:50 UTC
Created attachment 40353 [details]
rshd.c, rexecd.c: perform setuid before chdir

Comment 4 Alex Muntada 2001-12-11 18:22:21 UTC
I've found that the steps described above to reproduce this issue may not
fail in some scenarios, depending on the shell and environment settings
defined by the system and the user itself. These are the working ones:

Steps to reproduce: (1 and 2 are the same)
3. "rsh -l username hostname pwd" from a remote host.

Actual results:
/

Expected results:
/home/username

Comment 5 Alex Muntada 2001-12-13 14:52:35 UTC
After testing that the issue remains unresolved on the 7.2 version I've changed
the information
fields accordingly.

Comment 6 Phil Knirsch 2002-02-24 17:41:01 UTC
Good point... I'll fix that in the upcoming package...

As another workaround you can also always use the no_root_squash option in your
exports. NFS is already very insecure by design, so doing so on an internal
network shouldn't be much worse.

Read ya, Phil

Comment 7 Tor Lillqvist 2002-04-09 12:07:16 UTC
A similar problem is present in su. It does a chdir() after only calling setfsuid(). If the home directory is NFS-mounted (and exported with root-to-nobody mapping). and 
protected like:

drwxrws---   80 root     lillqto1   262144 Apr  9 12:26 /home/lillqto1

su won't be able to chdir() into it after just a setfsuid().  (We have home directories protected like this so that users can't chmod them by accident or on purpose. The 
group is a per-user group.)

To be really correct, su should try the primary group, and then each supplementary group, for each doing a setfsgid() and trying the chdir(). But 
if that is too much..., at least for the case above, where the home directory's group is the user's primary group, it's enough to just add a call to setfsgid(pw->pw_gid) 
after the call to setfsuid().


Comment 8 Alex Muntada 2003-06-20 20:21:04 UTC
The issue still unresolved in Red Hat Linux 9.


Comment 9 Phil Knirsch 2003-06-24 12:03:00 UTC
OK, sorry. Fixed now finally in rsh-0.17-17, soon available via rawhide.

Read ya, Phil


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