Joe Nall wrote:
On Fri, May 30, 2008 at 8:47 AM, Christopher J. PeBenito
<cpebenito@xxxxxxxxxx> wrote:
On Fri, 2008-05-30 at 08:19 -0500, Xavier Toth wrote:
On Wed, May 28, 2008 at 1:38 PM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote:
The current XAce software is far to complex to do anything usefull in my
opinion. We have way too many types and transitions. We need to
simplify down to a lot less types.
Going back to Dan's concern about the complexity of the X SELinux
extension and the number of types and transitions I'd like to see some
discussion/resolution. Eamon what's your position on this topic?
I don't want to speak for Eamon, but I suspect that he would defend the
current setup since he's the one that wrote the policy. I just
restructured it to fit nicer in refpolicy and actually removed a few
types :)
My position is that its fine as is. Simplifying it unconditionally
starts to make it less usable for people that actually want fine grained
controls on the desktop. Making things simpler tends to be easy, since
it tends to be merging types or using attributes for blanket access,
like unconfined does. The black magic voodoo that happens in the
xserver, that only a select few have previously known about, has only
recently been exposed via the SELinux controls. I feel that it may be
premature to simplify the policy, since side effects probably aren't
well understood yet. At least they aren't understood well by me yet.
I never signed up to write "the SELinux policy" for X. It is my
responsibility to document my work so that others can write such
policies, and I will do so. See my earlier private message (pasted below).
X policy will be an area where one size doesn't fit all. I'll try to
address the concerns in the "current diff" mail.
I can relate to that :)
Voodoo note: Any post-login setuid magic will have to allow the
xserver object manager to continue to audit.
Changing the UID isn't all that interesting to me; it's changing the
context that matters. If SDTLOGIN or pam_selinux.so could be used to
implement a setcon() solution, great. If we could launch the server
after the user logs in, even better.
I chimed in on this thread because we need to get MLS X up and running
locally in enforcing mode. I wanted to make sure that we (Ted and I)
understood the issues involved as much as possible before changing any
policy.
The documentation links in the pasted message below are the best way to
get started with understanding X.
---
I plan to get some documentation into shape for the upcoming X server
release. This will certainly include updated XACE hook documentation,
as well as rudimentary one-liner class and permission documentation that
can go in the table of classes and permissions I recall seeing somewhere
(but can't find at the moment). The only thing I have right now is a
large spreadsheet of X protocol requests and the permissions required
for each one. I will do my best to make sure this knowledge gets put
into a communicable form.
However, it is time for other people in this community besides myself to
start figuring how X works. The X Window System is not black magic; the
core X protocol is described at [1] and many of the X extensions
(additional calls that have been added over the years) are described at
[2]. A great place to start would be the Xlib programming manual [3].
Wikipedia also has pages on many of the popular extensions. After that,
the various conventions that have been established for using X: the
ICCCM, which describes the cut & paste protocol and other aspects of how
window managers work [4]. The NETWM standard, its successor [5]. The
XSETTINGS selection protocol [6]. Finally, all of the GNOME and KDE
conventions and non-conventions (which I do not understand, because I
have not gotten that far) and the requirements of the various "core"
desktop applications such as nautilus, gnome-panel, gnome-session, gdm,
gnome-screensaver, gnome-power-manager, gnome-keyring, etc.
People just know how files, symbolic links, pipes, and sockets work, and
they do not need Steve to explain this to them. X should not be any
different.
[1] http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/hardcopy/XProtocol
[2] http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/hardcopy/Xext
[3] http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/hardcopy/X11
[4] http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/hardcopy/ICCCM
[5] http://freedesktop.org/wiki/Specifications/wm-spec?action=show&redirect=Standards%2Fwm-spec
[6] http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html
--
Eamon Walsh <ewalsh@xxxxxxxxxxxxx>
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
