> Yet again, ioperm simply giove the program complete io permission (which
> is what svgalib otherwise does with the root priviledge). That means that
> the svgalib program gets complete access to any hardware, disk controller
> etc. It can circuvent any permission s and whatever. Easily break hardware
> by by making (dumb disks) run their heads against the disk case
I'm well aware of that. Since svgalib needs access to /dev/mem, it can
get root anyway if it wants. The point isn't to guard against attacks
in the programs themselves, but to help against stupid programming
bugs like buffer overflow which in turn can be used to mount attacks
from the outside (or simply crash the system). This is especially true
in contexts like networking games and/or programs with no source
available.
Surely even dropping privileges beforehand is not bulletproof either,
but it makes attacks harder. A simple exec() won't be enough to
exploit a stack smash, it needs at least code to scan the available
fds and the space for the attack code is not unlimited.
> Hence, do not let ioperm lul you in a false sense of security. The concept
No, I don't. As long as user level programs need any access to the
hardware directly they won't ever be secure against trojans and inside
attacks. The proper solution is to put the hardware access in the kernel.
> of graphixcs under linux and all other Unixens I know good enough to
> decide on that is just plain stupid. I dearly hope all this fb and kgi an
> dmesa stuff will once result in a sensible solution of this problem. But
> it will IMHO need a few more years to be ready for everyone at best.
Framebuffers are there, it's only the acceleration part of the X
server (or graphics library) that needs work. Perhaps it would even
make sense to split the video driver into a plain framebuffer and an
accelerator driver.
> > I've given up on svgalib since I got a machine fast enough for X ;-)
> which is what most people do. Alas, you now trust your Xserver 150% for
> security and X might gbe too slow (ok, at lerast slower than a direct
At least I can "trust" the X server to be under constant public
scrutiny. I don't claim there are no bugs in it, but they tend to get
fixed. Today's X servers are started with a wrapper too (at least on
SuSE and Debian systems). This doesn't make them 100% secure of
course.
> solotion could be) and it cant' change screen rez on the fly (ok, it can
> use different rez (by faking always tyhe same virtual screen size to
> applications) but not different color depths.
With xawtv the X server does change resolution on the fly. :-)
But the color depth remains a problem (I'm not sure if the X protocol
disallows that or it would "just" need dithering etc. put into the X
server.)
Olaf
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
