no need for suid root svgalib programs

[Joey Hess <joey@kitenet.net>]

-----Forwarded message from Olaf Titz <olaf@BIGRED.INKA.DE>-----

> Recently looking through the source of the suid root game called Lizards I

Why is this suid root? I assume it uses svgalib and the mistaken notion that
svgalib requires programs setuid root is still in every doc and HOWTO about
svgalib programming several years after this has been fixed.

Use "ioperm" <URL:http://www.inka.de/~bigred/sw/ioperm.txt> to run any
svgalib program (and more) without making them setuid. svgalib does properly
support running with this tool for a long time now.

There is no excuse at all for making any game setuid root.

olaf

-----End of forwarded message-----

Here is the text from that web site:

  Some time ago, I was asked by a friend about how user-level programs
  could access I/O ports (for specialized hardware, in his case) without
  the need to run as root all the time (obvious security
  considerations). This got me the idea of setting up a program that
  would run as root, set the I/O permissions, reset the UID and exec the
  user program. With a configuration file, the hardware access rights
  for several user programs could easily be specified.

  Originally, the version (0.8.something) of svgalib running on my
  machine had the same problem - every svgalib program must run setuid
  root. This is reflected by the enclosed examples and man pages. I just
  recently learned that newer versions of this particular library reset
  the UID on their own, so this isn't that necessary[1], but it could
  remain as an example on how to avoid setuid root programs if possible.
  The executed programs don't get any privileges other than I/O access
  to a specified range of ports and optionally a specified GID. For the
  svgalib case, the GID needs write access to /dev/mem which can be
  abused to get root, so this doesn't help against deliberate Trojan
  Horses but it can perhaps help against exploitable program bugs. This
  is of particular interest wrt. the original question where very
  special hardware and potentially large and complex user programs are
  involved. 

So this is basically a program like sudo, that gives svgalib programs the io
permissions they need to access memory. The man page for ioperm has a bit
more to say about svgalib:

       svgalib  has  to  be modified to not make any ioperm(2) or
       iopl(2) calls by itself. The  easiest  way  to  accomplish
       this  is to include in the libvga.a library dummy versions
       of these functions that always return 0.  svgalib requires
       access  to  the ports 0x3bd-0x3df (VGA hardware registers)
       and /dev/mem, which is given by making  /dev/mem  writable
       by group mem[2] and running the programs under this group.

However, I looked at the svgalib source and it knows about the ioperm
program and if am environment variable IOPERM is set, it doesn't do the
calls to ioperl() or iopl().

So it looks like we could have an ioperm package, and svga programs could
depend on it and register themselves in /etc/ioperm.conf, without any need
to modify svgalib.

-- 
see shy jo

[1] Of course, svgalib does give up suid root permissions when it
    initializes. However, there have been plenty of security problems in the
    past with suid games that waited too long to give up their suid root and
    were exploitable.
[2] We would use group kmem.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .