Bug 8641 - /etc/securetty don't understand pts/0
/etc/securetty don't understand pts/0
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
6.1
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-19 20:10 EST by Olivier Kaloudoff
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-10 15:05:14 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 Olivier Kaloudoff 2000-01-19 20:10:14 EST
I put:

pts/0
pts/1
pts/2
...

 in /etc/securetty to allow networked
root logins... but i am still unable to
login as root.
Comment 1 Riley H Williams 2000-01-20 17:00:59 EST
If you want to allow networked root logins (and massive security holes to go
with it), just delete /etc/securetty and that will happen. Remember that when
you're using telnet, the password you type is visible to anybody who runs a
packet sniffer, and a hacker seeing your root password broadcast like that will
assume that Christmas has come early.

A better choice is to use ssh to log in. It encrypts the password, as well as
everything else sent, so they can't be sniffed, and it allows network root login
by default.
Comment 2 Riley H Williams 2000-02-03 12:00:59 EST
I received a personal email from the reporter stating that (s)he wanted to be
able to log in across the network directly as root, and thought that the pts/X
notation should be allowed. I'm following up here for general comment, and would
like to make the following points:

 1. Let's say that "pts/0" was allowed, and was dropped in /etc/securetty
    to enable logins on that port. Ask yourself what this actually means.

    As I understand it, it basically says that the person who happens to
    be allocated "pts/0" for their telnet connection would be allowed to
    log in as root, but other users would not be allowed to.

    If so, then that means that the hacker who telnet'd in to your system
    two minutes ago can get in, as they were allocated "pts/0", but you,
    the rightful owner, can not.

    Alternatively, it means that you will still not be able to get in,
    except on the random occasions where you happen to get allocated to
    "pts/0" when you telnet in.

 2. If your intention is to be able to telnet in from anywhere on the
    Internet, remember that anybody running a packet sniffer (and even
    the lowly `tcpdump` command qualifies) would be able to read your
    username and password in plain text, and would thus have unhindered
    access to your system.

Given these two points, I still believe that my earlier suggestion to use `ssh`
instead of telnet is the correct one, since `ssh` ignores /etc/securetty in the
first place, and additionally ensures that your password never appears in plain
text to be sniffed.
Comment 3 Nalin Dahyabhai 2000-02-10 15:05:59 EST
You are correct that this is insecure, but on a system without Unix'98 pty
support, adding ttyp0, ttyp1, etc. still works.  As of pam 0.72 from Raw Hide
or Piglet, pam_securetty will assume the tty is in /dev/pts/ if you just use a
digit for the tty's name:

tty1
tty2
0
1
2
3

It's still not a safe thing to do in most if not all cases (for the reasons rhw
outlines), but it works.

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