dce@mips.UUCP (04/10/87)
(This may actually apply in a broad sense to a 4.2BSD system as well,
even though a different security method is used, but I don't have one
that I can try it on.)
In 4.3BSD, one can only login as root on a port if the port is marked
"secure" in /etc/ttys. If you try to login as root on a port not marked
as such, the message "Login incorrect." is printed and you get a new
login prompt.
Our system administrator ran into this a couple of weeks ago when working
a newly-installed system (we don't ship /etc/ttys with ptys marked as
secure; should we?).
This struck him (and me) as odd, since the classic scenario in Unix
security is that login should *always* prompt for a password to make
sure that someone trying to break in can't tell if the username is
valid or not. The idea is that telling a breaker that an account name
is or isn't valid is giving him/her an edge, and so should be avoided.
Is there a good reason that login shouldn't go ahead and prompt for a
password in this case just for the sake of consistency?
--
David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dcerlk@bacchus.UUCP (04/10/87)
In article <274@quacky.mips.UUCP> dce@quacky.UUCP (David Elliott) writes:
[Discussion of logging in as root on an unsecure tty].
]Is there a good reason that login shouldn't go ahead and prompt for a
]password in this case just for the sake of consistency?
None that I can think of. In addition, there's another reason why it
should ask for the password. If someone has the root password, and
tries to log in on an unsecure tty, then login could detect that the
correct password is being used and log a message indicating what
happened.
Note that 4.3 also prevents su's to root from people not in group
operator (or is it wheel?). This prevents, say, someone logging in as
a random and then su'ing. Su should also log attempts by people not
in the right group, for the same reason.
Robert^Zavolio@decuac.UUCP (04/11/87)
In Ultrix-32 V1.2 and in V2.0 this works correctly. I suspect it should in 4.3BSD also. (Correctly meaning it asks for password too and then gives "Login incorrect.") It sounds like there was no root password on the new system (likely?) Fred
gamiddleton@watmath.UUCP (04/12/87)
In article <437@bacchus.MIT.EDU> rlk@athena.MIT.EDU writes: > None that I can think of. In addition, there's another reason why it > should ask for the password. If someone has the root password, and > tries to log in on an unsecure tty, then login could detect that the > correct password is being used and log a message indicating what > happened. > > Note that 4.3 also prevents su's to root from people not in group > operator (or is it wheel?). This prevents, say, someone logging in as > a random and then su'ing. Su should also log attempts by people not > in the right group, for the same reason. We didn't like the 4.3 behaviour, so we replaced with our own way of doing things. In our /etc/passwd file, the entry for root has a password of '*', so one can never log in as root directly. Instead, there is a file /etc/super-users, which contains a list of users allowed to become root, and a password for each. /bin/su checks this file. We got rid of the group-wheel stuff; it was unnecessary. -Guy Middleton, University of Waterloo MFCF/ICR, gamiddleton@watmath
wolfgang@haddock.UUCP (04/12/87)
In article <274@quacky.mips.UUCP> dce@quacky.UUCP (David Elliott) writes: >In 4.3BSD, one can only login as root on a port if the port is marked >"secure" in /etc/ttys. If you try to login as root on a port not marked >as such, the message "Login incorrect." is printed and you get a new >login prompt. >Is there a good reason that login shouldn't go ahead and prompt for a >password in this case just for the sake of consistency? Yea, I'll bet that login never gets called. Getty probably reads /etc/ttys, prompts you with "Login: ", gets your login name, notices that its root, and *never* calls login. Hence it can't easily fake the pasword prompt and encryption delay. Remember, it's only the second "login: " prompt that comes from login (if you screw up the first time). -- using a freind's account, please reply to: Alison Chaiken mirror!mit-mgm!alison
dce@mips.UUCP (04/12/87)
In article <6853@watmath.UUCP> gamiddleton@watmath.UUCP (Guy Middleton) writes: >In article <437@bacchus.MIT.EDU> rlk@athena.MIT.EDU writes: >> >> Note that 4.3 also prevents su's to root from people not in group >> operator (or is it wheel?). This prevents, say, someone logging in as > description of a files of people that can su... >and a password for each. /bin/su checks this file. We got rid of the >group-wheel stuff; it was unnecessary. I didn't like the idea of forcing people to be in group wheel, either, though for a commercial product to go against the base release is a bad idea. A pretty clean solution is to change the check to be if (getegid() != 0 && {user not in group wheel}) { {disallow} } and allow su to be setgid wheel. This way, system administrators can choose whether the check is made for themselves just by using chmod. -- David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dce
cudney@sdcrdcf.UUCP (04/13/87)
In article <437@bacchus.MIT.EDU> rlk@athena.MIT.EDU writes: > In article <274@quacky.mips.UUCP> dce@quacky.UUCP (David Elliott) writes: > ] [Discussion of logging in as root on an unsecure tty]. > ] Is there a good reason that login shouldn't go ahead and prompt for a > ] password in this case just for the sake of consistency? > None that I can think of. ... >Robert Consistency may be less a factor than the risk of exposing the root password in clear text on a tapped line. No system should encourage a person to do something thoughtless. Asking for the root password on an unsecured line is just such a design fault. Consider your exposure on some local area networks, and think again. /Paul
guy%gorodish@Sun.COM (Guy Harris) (04/13/87)
> Getty probably reads /etc/ttys, prompts you with "Login: ", gets your > login name, notices that its root, and *never* calls login. Nope. The 4.3BSD "getty" never looks at the "secure" flag. "login" does this check, based on the *user ID* of the account, not its name.
dce@mips.UUCP (04/13/87)
In article <434@haddock.UUCP> wolfgang@haddock.ISC.COM.UUCP (Wolfgang Rupprecht) writes: >In article <274@quacky.mips.UUCP> dce@quacky.UUCP (David Elliott) writes: a bunch of really stupid, useless drivel. > >Yea, I'll bet that login never gets called. Getty probably reads Sorry, but that's not it. I looked at the code and the check is in login. In reality, the person from DEC was right. The machine in question was a virgin machine, which meant that it had no root password. Because of this, login just passed over that part and went on to the secure tty check, which proved to be false, and the connection was closed. Sorry to have bothered everyone. We can now get back to the discussion of why it is silly to force people to have mixed case passwords. -- David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dce
lrj@batcomputer.UUCP (04/13/87)
In article <274@quacky.mips.UUCP> dce@quacky.UUCP (David Elliott) writes: >In 4.3BSD, one can only login as root on a port if the port is marked >"secure" in /etc/ttys. If you try to login as root on a port not marked >as such, the message "Login incorrect." is printed and you get a new >login prompt. >Is there a good reason that login shouldn't go ahead and prompt for a >password in this case just for the sake of consistency? Ummm... I just tried it on my system and it asks for the password. This works on both network and hard-wired terminals not marked as 'secure' in /etc/ttys. I'm running the final 4.3BSD release on a Vax 11/750 with getty and login unchanged from the copy of the release tapes i got. Messages about the attempts at root login were also printed on the console. The only two terminals that are 'secure' are in my machine room -- i figure if someone's gotten that far, there isn't a lot i can do anyway. :^) So, it almost sounds like you're running some beta version of 4.3BSD, and they 'fixed' this by the final release. -- -- Lewis R. Jansen, LASSP Systems Grunt lrj@lasspvax.tn.cornell.edu ...!cornell!lasspvax!lrj The above opinions are for sale or rent. Inquire within.