Fedora: RFC: X.Org X11 modularization project - rpm package driver naming

Posted Aug 29, 2005 20:07 UTC (Mon) by proski (subscriber, #104)
In reply to: Fedora: RFC: X.Org X11 modularization project - rpm package driver naming by job
Parent article: Fedora: RFC: X.Org X11 modularization project - rpm package driver naming

The trade-off would be having the driver in the kernel, which is not necessarily safer than a SUID process.

Fedora: RFC: X.Org X11 modularization project - rpm package driver naming

Posted Aug 30, 2005 1:54 UTC (Tue) by brouhaha (subscriber, #1698) [Link] (2 responses)

It wouldn't have to be a kernel-level driver. There's no reason why the kernel can't make device files available that can be mmap()ed to get at the PCI card memory spaces. I experimented with this almost ten years ago just mmap()ing /dev/mem to get at the frame buffer, and proposed on lkml that /proc/pci should provide device files representing each memory space.

At the time, a few vocal people shouted me down, with ridiculous complaints that it would make the system less secure. That was (and is) complete BS, because any process that runs SUID root can wreak just as much havoc using /dev/mem and other means as it could with my proposed /proc/pci device files.

Anyhow, what I was proposing back then was that the /proc/pci device files would normally have permissions like 600, but nowdays there's no reason that more sophisticated access control couldn't be used, in order to allow a non-SUID X server to access the video card.

This also would remove the redundant PCI bus scanning code from the X server. The kernel already has done it, so there's no reason for the X server to do it again.

Fedora: RFC: X.Org X11 modularization project - rpm package driver naming

Posted Aug 31, 2005 0:54 UTC (Wed) by proski (subscriber, #104) [Link] (1 responses)

As far as I know, all new security extensions can only restrict access but not to add new permissions. You cannot start with a non-suid binary and give it an "endorsement" it to access PCI bus. You still have to start with a suid binary and restrict its permissions, which is what you can do now without any code changes.

I hope you would agree that permitting raw PCI access for non-privileged applications would mean a much bigger security problem than running X server suid root.

Fedora: RFC: X.Org X11 modularization project - rpm package driver naming

Posted Sep 1, 2005 10:37 UTC (Thu) by farnz (subscriber, #17727) [Link]

It's not a security extension; it's a set of devices which expose raw PCI access to userspace. You can then chmod/chown/chgrp each PCI device suitably (so that the "graphics" group can play with the video card), then run X SGID as graphics.

Fedora: RFC: X.Org X11 modularization project - rpm package driver naming

Posted Sep 1, 2005 9:56 UTC (Thu) by job (guest, #670) [Link]

I would like a kernel video driver, if the interface is good enough it has the opportunity to really clean up the mess that is svgalib, directfb, x11 so VC switching works properly between them. Hopefully in a better state than today so it is trivial for an app to use several VCs, several monitors etc.

And a most people with modern PCs probably already have a video driver in the kernel, either the nvidia/ati proprietary ones or DRI. That API could be extended with some protection/separation and 2D acceleration and used by all the graphics subsystems for Linux.

My main point is that I would like the privileged part of X11 to become smaller by orders of magnitude. There is a lot of code there running with full privileges that doesn't really need them. And root access is for all practical purposes just as bad as kernel level access.