Subject: Re: Problems with root and .rhosts
To: Brian Moore <email@example.com>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 10/28/1994 13:07:08
>I totally agree with your points about adding the option to rlogind, it would
>be silly. IMHO, I think the ptys should interact with telnetd, rshd and
>rlogind like so:
s/totally agree with/missed some of/ 8-)
>1) If the pty entry in /etc/ttys is marked as insecure, then telnetd, rshd and
> rlogind show all disallow root access for that specific pty.
I didn't say (or) think that, at all, for 'rsh'. that would change
historic practice in a _serious_ way, and screw lots of things up.
'secure' determines whether 'login' allows logins on a given tty.
I was wondering if it was reasonable to just allow 'rlogin's
as root in general, or make them do some sort of special check for
security on the pty.
Most other systems allow them unconditionally, but _do_ require
a 'secure' tty, if the login wasn't .rhost-ed. The latter is already
taken care of by rlogind's invocation of login.
>2) If the pty entry in /etc/ttys is maked as secure, then telnetd should allow
> root logins for that pty.
> 2a) In addition, if a proper .rhosts file exists for root, then it
> should be used by rlogind and rshd.
What you're missing here is the layering involved. telnetd doesn't
doesn't make any decisions about secure ttys. neither does rlogind.
they both allow 'login' to make such desicions.
rlogin ---->| (not authenticated) |----->|
| (authenticated) |-------X--------> login -f
rsh -------->| (authenticated) |---------------> running command
| (not authenticated) |-\
\---------> Permission Denied.
the question that this discussion brings up is:
what should be done for authenticated rlogins, where the
id being logged into is 'root'?
(i.e. what should happen on the X-marked path when logging
in as root?)
the other paths through that tree:
authenticated rlogins where the id being logged into is not root, and
authenticated and non-authenticated rsh's
are already satisfactorily handled, and to change any of them (esp.
the latter pair) would seriously screw with people's minds and
The current behaviour for the case in question is:
Always disallow authenticated root rlogins, in rlogind..
the other two possible behaviours are:
Allow authenticated root rlogins iff the 'secure' flag
of their tty line is set.
Always allow authenticated root rlogins.
Either of those can be accomplished by getting rid of the uid check.
in rlogind. The behaviour of one of the other can then be picked in
login, in it's handling of -f.
(Note that there's a serious problem that could arise from changing
login to check the tty's secure flag for authenticated logins: then
authenticated kerberos rlogins as root would be subjected to the
check as well, which is inappropriate.)
What it really boils down to is:
(a) what should happen with authenticated kerberos rlogins
as root. [i think they should stay the same, so one
can't easily check for the secure flag on the tty.]
(b) should authenticated rlogins as root be allowed at all?
[other vendors seem to think it's OK.]
(c) how much utility is gained by allowing root rlogins to
succeed? [some, not too much.]
(d) how much security is lost? [again, some, not too much;
it makes it more difficult to see who exactly used
root, and there are possibilities of spoofing rlogin
further thoughts? I asked around, and apparently that uid check
on rlogin has been around for a long, long, long time. I guess
(most?) vendors have removed it, though.