From: Bart Oldeman (Bart.Oldeman@bristol.ac.uk)
Date: Wed 28 Feb 2001 - 18:54:30 IST
On Mon, 26 Feb 2001, Matan Ziv-Av wrote: > This requires a few clarifications: > X also writes directly to the hardware, and so, X needs root privileges > as well. The difference between programs using X and programs using > svgalib is that the X server is a different process, and programs draw > to it using an IPC mechanism. Svgalib functions run in the same process > that the actual program runs, and so the whole program needs the root > privileges (for the access setup stage). > > About the /dev/svga device - this is a kind of a camouflage for the > proglem, and it does not increase safety by much. As currently > implemented it is even less safe. Instead of a few (tested) programs > being suid root and having access to the video hardware, now any user > who can run svgalib programs needs access rights to /dev/svga, which > means she has full access to the video card. On most video cards this > means an ability to crash the system, and on some cards an ability to > gain root provileges (though this is theoretically only. I never saw an > actual exploit). > > The usefulness of the kernel module, comes in arbitrating access between > multiple programs and multiple cards, and eventually it will be as > secure as the current method, but no more. I guess this must have been discussed before, but would it be possible to program an svgalib server daemon, so that non suid-root programs can still write directly to the video memory, but I/O ports can only be manipulated by svgalib functions using an IPC mechanism? That way svgalib would become more of a framebuffer-manipulation library that can communicate with the svgalib server and fbdev. (Hmm, wasn't GGI supposed to solve all problems?). Bart ------------------------------------------------------------------ Unsubscribe: To: listbot@svgalib.org Body: unsubscribe linux-svgalib
This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:23 IST