From: jeffw@cs.tamu.edu (Jeffrey A Waller) Subject: Re: ANNOUNCE: GNUPLOT 3.2 uploaded to sunsite.unc.edu Date: 26 Feb 1993 23:36:43 GMT
In article <1993Feb26.145602.13308@wam.umd.edu>, joel@wam.umd.edu (Joel M. Hoffman) writes:
|> In article <HEIM2.93Feb26135029@sally.peanuts.informatik.uni-tuebingen.de> heim2@peanuts.informatik.uni-tuebingen.de (Gerald Heim) writes:
|> >-rwxr-sr-x 1 bin mem 238596 Dec 4 11:02 /usr/local/bin/gnuplot*
|> >crw-rw---- 1 root mem 1, 2 Aug 29 23:48 /dev/kmem
|> >crw-rw---- 1 root mem 1, 1 Aug 29 23:48 /dev/mem
|> >
|> >... if you don't want others to become root w/o password :->
|>
|> Unfortunately, this too is a security hole. The whole point not
|> making /dev/[k]mem world readable is that doing so is a secuty hole.
|> With the permissions you suggest, anyone can run gnuplot, escape to a
|> shell, and access /dev/[k]mem. Bad idea.
|>
|> I guess a better solution would be to modify the shell escape to
|> restore the old userid.
|>
|> -Joel
Yes, now setgid mem processes can *write* to kernel memory. What
stops them from going through the process table, finding the
task_struct of any process they want and resetting the uid and euid
fields to 0?
Total ignorance on my part, but why does gnuplot have to read
(or write) to kernel memory? How about some kernel mods with
/dev/vga, /dev/framebuffer and some nice ioctls?
-Jeff