Xref: utzoo comp.emacs:6724 comp.bugs.4bsd:1373
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!umbc3!mark
From: mark@umbc3.UMBC.EDU (Mark Sienkiewicz)
Newsgroups: comp.emacs,comp.bugs.4bsd
Subject: Re: Interactive shells in emacs:  a security problem?
Keywords: emacs, ptys, security
Message-ID: <2255@umbc3.UMBC.EDU>
Date: 23 Aug 89 15:32:28 GMT
References: <6973@sdcsvax.UCSD.Edu>
Reply-To: mark@umbc3.umbc.edu.UMBC.EDU (Mark Sienkiewicz)
Distribution: na
Organization: University of Maryland, Baltimore County
Lines: 47

In article <6973@sdcsvax.UCSD.Edu> mattson@beowulf.UCSD.EDU (Jim Mattson) writes:
>
>When I run an interactive shell in GNU emacs or Jove, the editor provides me
>with a pty that looks like this:
>crw-rw-rw-  1 root      10,   4 Aug 22 17:31 /dev/ttyp4
...
>As a result, my interactive shell is at everyone's mercy.  I might as well
>post the password to my account.
...
>of the pty connection.  Maybe there should be an ioctl that allows a
>regular user to make himself/herself the owner of an open pty connection.
>That seems really awful, though.  Are there other solutions?

You could arrange for the pty device driver to change the owner of the 
tty?? file for you.  Suppose the steps looked like this:

1) emacs (or whatever) opens ptyp0 to use as a master for an interactive shell.
2) the driver notes the uid & gid of the emacs (or whatever) process.
3) A child processes is created which opens ttyp0 for it's control terminal.
   The pty driver does a little tracing back through the kernel structures
   to find the inode (in core, of course) for ttyp0 and changes it's owner
   fields to match the owner of the process that allocated the pty.
4) the last close of ttyp0 changes the owner back to root and the permissions
   back to 0666.

Then the only responsibility remaining for the user program is to fix
the protections after allocating the pty.  

Doing something like this should be relatively painless except for finding
the inode that open was using.  Even for that, you could brute force search
all in-core inodes for something that matches the major/minor number that
was handed to ptyopen().  I can see 2 problems with this approach:

1) it's kind of a non-elegant way to do it.  device drivers aren't really
	supposed to mess with things like that.

2) If you do 2 mknod's for the same minor number of a tty device, you
	can see your original problem come back.  Don't do this.

Anybody see why this should'nt work?


-- 
			Mark S.

uunet!umbc3!nerwin!zilla!mark
nerwin!zilla!mark@umbc3.umbc.edu