Bug 2611 - /dev/pts default permissions WRONG! Security risk
/dev/pts default permissions WRONG! Security risk
Status: CLOSED DUPLICATE of bug 3025
Product: Red Hat Linux
Classification: Retired
Component: basesystem (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-05-06 17:25 EDT by Chris Evans
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-06-15 18:09:52 EDT
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 Chris Evans 1999-05-06 17:25:52 EDT
Hi!

/dev/pts is mounted "mode=0622". This is WRONG - it bypasses
the security on write. /dev/pts _should_ be mounted
"mode=0620,gid=5" (gid 5 is tty on the system)

The problem is worse though - xterm and nxterm work properly
with the above change, as do telnet logins. Unfortunately
screen and rxvt (maybe others) change the /dev/pts
permissions such that everyone has write acess and the
group is the user's group NOT tty.

Aside from this slip up I have been VERY impressed with
RH6.0 security.

Re-reading my message I'm not sure I've been clear - drop me
a note if any clarification is needed. Sorry about the duff
package too but /etc/fstab isn't owned by any package

Cheers
Chris
Comment 1 David Lawrence 1999-05-07 14:04:59 EDT
This has been assigned to a developer for further review.
Comment 2 Cristian Gafton 1999-05-09 02:39:59 EDT
I don;t really think this is a security problem - this is no change
from the previous ttyp* devices permissions. If somebody enables 'mesg
y' on their console they are open to a DOS. This will be probably be
handled more tightly in the future, but that will require engineering
in a lot of places to get it right.

For now, 'mesg n' takes care of all the problems. We will address this
issue in a next release, though. I am marking the bug as 'later' - we
will look back at it and fix it when we have a full understanding of
all the places we have to look at to take care of this problem
effectively.
Comment 3 Chris Evans 1999-05-09 07:12:59 EDT
Hi Cristian,

Sorry to be awkward but I must disagree with your comment "no changes
from the previous device permissions".

If I telnet to RH5.2 system I see

/dev/ttyp8  crw--w----  chris   tty

On RH6.0 I see

/dev/pts/0  crw--w--w-  chris   chris

The difference is crucial; under RH6.0 a malicious user can send any
arbitrary character stream to a tty. Some terminals can be
reprogrammed so a given key can be made to map to a sequence of the
attackers choice...

Under RH5.2 only the "write" program (and talkd) has sufficient
privilege to send text to tty's - and the "write" program filters out
malicious sequences AFAIK.

So RH6.0 represents a lowering in tty security :-) To fix this isn't
too bad; the line for the /dev/pts filesystem in fstab needs changing
as I originally suggest. Also, screen and rxvt need to be made to
desist from changing the pty permissions from 0620 to 0622.

As an aside note that console logins on RH6.0 get the tty1/tty?
permissions correct e.g.

/dev/tty1  crw--w----  chris  tty
Comment 4 carenas 1999-06-11 11:42:59 EDT
Hi, i've tested this agains't my redhat 6.0 box and the solution
pointed by chris works well against, xterm, telnet, nxterm,
gnome-terminal and kterm

rxvt needs a simple patch to honour the tty group, you could get the
(S)RPMS (unsigned) for ftp://ftp.lared.net.pe/pub/linux/carenas, or
you can build your own.. adding --enable-ttygid on the configure call
on %Build,

seems like screen is also affected, and kvt (from KDE) doesn't even
honour the new Unix98 pty
Comment 5 Bill Nottingham 1999-06-15 18:09:59 EDT
*** This bug has been marked as a duplicate of 3025 ***

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