Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.questions
Subject: Re: Can the output to a terminal be monitored?
Message-ID: <1990Jun12.003058.2445@virtech.uucp>
Date: 12 Jun 90 00:30:58 GMT
References: <2784@syma.sussex.ac.uk> <270@demott.COM> <1990Jun3.011111.1589@virtech.uucp> <509@al.ele.tue.nl>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 29

In article <509@al.ele.tue.nl> raymond@ele.tue.nl (Raymond Nijssen) writes:
>
>    [ discussion of reading clists from /dev/kmem deleted ]
>
>These programs
>are used by crackers, and it's quite easy for them, since /dev/kmem is
>world readable on most unix systems, for this is necessary for commands
>like ps, which examines lots of kernels buffers also.
>
>CPU time, so i doubt whether it can be of use for monitoring an outgoing line.
>Nevertheless, it should still be considered as a security hole, and I 
>wonder if it has been fixed in rel. 4.

It is not a bug in most versions of unix.  The programs that need to access
/dev/kmem are usually set up to run as set-gid to the same group as the 
/dev/kmem entry, thereby only requiring group read access on the device,
not general read access.

PS-> ps doesn't read many kernel "buffers".  It reads the process table and,
if necessary, the u structure for each process.  The rest of the information
it uses comes from disk files (either /etc/passwd & associated files or the
quick condensed version in /etc/ps_data).  It may have to read some of
the paging/swaping stuff to get the user structure info for swapped out
processes.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170