Path: utzoo!attcan!uunet!lll-winken!ames!ncar!tank!mimsy!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.unix.wizards Subject: Re: Terminals are ridiculously insecure Keywords: terminal, abuse, insecurity Message-ID: <9324@smoke.BRL.MIL> Date: 10 Jan 89 03:09:00 GMT References: <5228@phoenix.Princeton.EDU> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 32 In article <5228@phoenix.Princeton.EDU> bernsten@phoenix.Princeton.EDU (Dan Bernstein) writes: >There is no rational reason that a process should be able to keep >access to a tty once its owner is no longer the owner of the tty. You can argue this for interactive login ports, but it's definitely false for other tty ports. If there is a serial printer on /dev/ttyP, there is no reason in the world anyone with proper permissions should not be able to "cat file >/dev/ttyP". (This is the simplest example; don't divert this into a discussion of use of spoolers.) >I should think that a terminal with nobody logged on should be readable >and writable by nobody, i.e., mode 000. It doesn't make sense otherwise. That's certainly one approach that addresses the REAL security hole. Some time ago, we had a discussion about use of "public filesystem resource (including device) allocators", the idea being that free resources could belong to the allocator daemon, which of course would be the sole UID with access permission. There was also some discussion about allocation of ptys and corresponding utmp maintenance. If somebody wants to work on this "problem" and really solve the tty administration RIGHT, it would be wise to factor in those notions. >3. This discussion brings up another point about UNIX. There are very >few ways to re-check all the open descriptors referencing a file for >permission on that file. vhangup() is about the closest things come. There really are applications that rely on the ability to continue access to an open descriptor after the inode permission have been changed. That in itself is not a security problem. Let's fix the real holes and not try to remove useful abilities from UNIX simply out of paranoia.