Re: [PLUG] Postscript, Ghostscript, and pdf

[Kevin Brosius <kbrosius@kns.com>]

gabriel rosenkoetter wrote:
> 
> On Thu, Oct 11, 2001 at 02:03:55PM -0400, Kevin Brosius wrote:
> > Very few XFree86 drivers have access to DMA (and of the _one_ I can
> > think of, it only does that on Linux.)  What did you really mean to say?
> 
> What you say is contradicted by http://www.xfree86.org/4.1.0/NetBSD7.html:
> 
>   By default NetBSD include the BSD 4.4 kernel security feature that
>   disable access to the /dev/mem device when in multi-users mode.
>   But XFree86 servers can take advantage (or require)
>   linear access to the display memory.
> 

No, I still disagree.  Having 'linear access' to the video cards' memory
is not the same (and not a security risk like I think you are implying)
as having access to DMA facilities on the motherboard/video card.  The
display memory is linearly mapped on a majority of XFree86 drivers today
from the X server which is privileged.  However, the linear video memory
mapping does not include the DMA registers.  At least not when it is
passed to userland.

> >>Most XFree86 4.1.0 card drivers require linear memory access.
>   There are two ways to allow XFree86 to access linear memory:
> 
>   The first way is to disable the kernel security feature by adding
>   ``option INSECURE'' in the kernel configuration file and build a
>   new kernel.
> 
> It's most obvious in NetBSD merely as a result of any (secure) 4.4
> BSD kernel's securelevel feature. It is necessary to leave the
> kernel in securelevel 0 (linear access to memory in order to get
> blit images to the graphic card's DMA quickly, so not *precisely*
> what I said, but the point is the same) in order for XF86 to work.
> 

It's important that you don't say DMA and linear access together.  The
XFree86 drivers normally map _video memory_ and may make it available to
userland (ie. DGA).  This does not give userland access to anything
outside video memory, such as DMA registers on the video card that could
be a risk to other memory space.  Writing to _video memory_ only affects
what you see on the screen.  Are you suggesting that this is a security
risk?

Think of it like this.  The X server has multiple regions of memory
mapped on the video card.  Some are security risks (DMA registers, PCI
config registers), some are not (video memory).  If a memory region is
passed to userland, it is just that, a mem-mapped region of video memory
which userland can modify, but is bounds protected like any other memory
block in the system.

> They go on to suggest that the other option is to use their aperature
> driver (a kernel module) which allows only one process to have linear
> memory access at a time, but this is tantamount to the same thing
> as a userland process can take over the console extremely easily,
> relative to how easily it can get kernel-level access to memory when
> the kernel is at securelevel 1 (it's impossible to do so without
> finding a buffer overflow in a syscall exported by the kernel, and
> it'd be pretty damn hard even then). And don't even get me started
> on how I feel about adding third-party LKMs to my kernel as a
> "security measure".
> 
> It should be noted that it is *not* necessary to open this security
> hole in order to run X11R6. None of the Xmac68k, Xsparc[64],
> Xsgimips, and Xmacppc servers (all internally developed for NetBSD)
> need this.
> 
> The fact that Linux doesn't have securelevels doesn't mean it
> doesn't have this problem; it means there's no way for it *not* to
> have this problem. Linear access to memory from userland (which
> *includes* root) is bad, the reasons for which I hope are obvious.
> 

Well, my point here is that the XFree86 X server is designed to only
give memory access to the video graphics memory to userland, nothing
else.  If you don't want to run acceleration because you consider this a
security risk then you need to run one of the VGA/SVGA drivers which
doesn't need full access to the video card. 

> (Think about unlocked private keys, in-transit IPSec sessions, do I
> need to go on?)
> 
> --
>        ~ g r @ eclipsed.net
> 

-- 
Kevin Brosius

______________________________________________________________________
Philadelphia Linux Users Group       -      http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion  -  http://lists.phillylinux.org/mail/listinfo/plug