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