Bug 8641
Summary: | /etc/securetty don't understand pts/0 | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Olivier Kaloudoff <kaloudoff> |
Component: | pam | Assignee: | Cristian Gafton <gafton> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 6.1 | CC: | rhw |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-02-10 20:05:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Olivier Kaloudoff
2000-01-20 01:10:14 UTC
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. 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. 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. |