X (was: New version of capabilities patch online, some more status)

[Timothy Fraser]

Hi!

On Thu, 27 Apr 2000, Ilmar S. Habibulin wrote:

> IMHO, there would be enough to implement X server, which could act on one
> level (and serve clients which have only this level) in a multi-level
> environment. This clipboard stuff is a headache. So i think that it is
> your first variant.

	If you want to add security functionality to X, I'm sure this
would be a fun project and a great way to learn about how X works.
However, if you'd rather concentrate on improving the security
functionality of the FreeBSD kernel, then you may want to take Ilmar's
advice.  I took the route Ilmar described while working on LOMAC, and it
allowed me to produce a useable system (at least between crashes <wink>)
without modifying any user-space applications.

	LOMAC adds MAC functionality to the Linux kernel.  It treats
user-space applications (like the X server and all X applications) as
black-box "subjects" that read and write black-box "objects".  It was
difficult for LOMAC to enforce any meaningful separation between X
applications (for example, to allow a single X server to support xterms at
different privilege levels), because all of the applications shared data
by reading and writing to the same set of objects (such as the UNIX domain
sockets that appear under /tmp/.X11-unix).  So when I use X with LOMAC,
all my X applications run at the same privilege level.

	It was my suspicion that you could run two X servers
simultaneously (one on virtual display 0 and the other on virtual display
1), and have them at different privilege levels.  (Linux let you switch
between virtual displays, and consequently privilege levels, by hitting a
very strange combination of control and function keys.  I think FreeBSD
also has this functionality.)  I never actually managed to do this,
because it would have required me to add an exception that would cause
LOMAC to ignore the fact that both servers like to read and write to the
mouse device.  Just my $0.02 ...

				- Tim


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message