All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eamon Walsh <ewalsh@tycho.nsa.gov>
To: Glenn Faden <Glenn.Faden@sun.com>
Cc: Xavier Toth <txtoth@gmail.com>, SE Linux <selinux@tycho.nsa.gov>
Subject: Re: X avcs
Date: Thu, 10 Jan 2008 15:27:54 -0500	[thread overview]
Message-ID: <47867FCA.50408@tycho.nsa.gov> (raw)
In-Reply-To: <477BEFF1.2090507@sun.com>

Glenn Faden wrote:
> This is my first posting to this alias, so let me start by introducing 
> myself. I'm a Distinguished Engineer in the Solaris security 
> organization, and I'm the original architect for Sun's multilevel X11 
> server. I have worked on this problem since 1990, and have designed 
> three multilevel desktops (Open Look, CDE, and GNOME)
>
> One of the biggest challenges in adding fine-grained policy to the X11 
> server is to make the policy transparent to existing X11 clients. 
> Probably the most critical design decision we made was with respect to 
> root window resources. By default, all root window properties are 
> polyinstantiated by both label and uid. For SELinux, the equivalent 
> policy would be polyinstantiation by security context (not just MLS 
> label). An exception list of single-instance root-window properties is 
> enumerated in a policy file.
> We have found that the list of exceptions is much smaller than the list 
> that should be polyinstantiated.
>   

Hello.  I am not opposed to the idea of polyinstantiated properties.  
Although our approach has always been to attempt to fix applications to 
work within the secure environment first, it looks like this is a case 
where polyinstantiated is needed.

My first thought on the implementation is that a value-return parameter 
could be added to the PROPERTY_ACCESS hook so that security modules can 
return the actual PropertyPtr object they wish to be used.  The 
FindProperty function would then have to be upgraded to a general lookup 
function similar to dixLookupResource(), dixLookupDrawable(), etc. and 
the property code would have to be refactored to use it everywhere when 
looking up a property.  The semantics of the various property requests, 
in particular RotateProperties, might make this a little more difficult.

SELinux has a security_compute_member() interface that is intended to 
return the security context of the appropriate object for use, and this 
can be used to determine which object to return.

> With respect to the root window drawable, it is protected at the lowest 
> label, so it is never modified. Applications like Nautilus are 
> polyinstantiated, too, and render their own background windows.
>
> Our implementation is all open-sourced using the Xorg license. A summary 
> of the X11 security policy implemented by Solaris Trusted Extensions is 
> described in Chapter 6 of the Developer's Guide,  
> http://docs.sun.com/app/docs/doc/819-0869/6n391u3ru?a=view
>
> The configuration file for the polyinstantiation policy is described in 
> the TrustedExtensionsPolicy man page, 
> http://docs.sun.com/app/docs/doc/819-7307/trustedextensionspolicy-4?a=view
>
> The source code which implements this policy can be viewed in the 
> OpenSolaris browser using this link:
> http://src.opensolaris.org/source/xref/fox/fox-gate/XW_NV/open-src/xserver/xorg/sun-src/tsol/
>
> The hooks to the XACE extension layer (also used by SELinux) are in the 
> file tsolCompat.c, which can be viewed here:
> http://src.opensolaris.org/source/xref/fox/fox-gate/XW_NV/open-src/xserver/xorg/sun-src/Xext/tsolCompat.c
>
> Although Trusted Extensions and SELinux have significant differences 
> with respect to their security models, both systems attempt to implement 
> MAC policy in a manner that is transparent to applications. This should 
> apply to the desktop, as well. In general, the user experience running 
> GNOME on Solaris (with or without Trusted Extensions) or on Linux (with 
> or without SELinux) should be almost identical. So the underlying 
> policies enforced by the X11 server should follow the same general 
> principles.
>   

Our long-term goal is to make applications aware of and responsive to 
the security environment, particularly applications that could 
themselves be multi-level such as e-mail, web, office.

-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  parent reply	other threads:[~2008-01-10 20:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-26 21:01 X avcs Xavier Toth
2007-12-28 16:54 ` Xavier Toth
2007-12-28 19:34   ` Eamon Walsh
2007-12-28 21:26     ` Xavier Toth
2008-01-02 15:11       ` Xavier Toth
2008-01-02 20:11         ` Glenn Faden
2008-01-09 14:21           ` Ted X Toth
2008-01-09 17:46             ` Glenn Faden
2008-01-10 21:14               ` Eamon Walsh
2008-01-10 23:55                 ` Glenn Faden
2008-01-10 20:27           ` Eamon Walsh [this message]
2008-01-10 23:27             ` Glenn Faden
2008-01-11 14:46             ` Ted X Toth
2008-01-11 20:46               ` Glenn Faden
2008-01-11 22:37                 ` Ted X Toth
2008-01-17 22:07                 ` Eamon Walsh
2008-01-21  2:04                   ` Glenn Faden
2008-01-24  0:11                     ` Eamon Walsh
2008-01-24 15:40                       ` Xavier Toth
2008-01-29 15:48                       ` Xavier Toth
2008-01-31  2:26                         ` Eamon Walsh
2008-02-08 23:51                           ` Eamon Walsh
2008-02-13 16:52                             ` Xavier Toth
2008-02-15 14:53                             ` Xavier Toth
2008-02-15 17:18                               ` Eamon Walsh
2008-01-11 23:04               ` Eamon Walsh
2008-01-14 20:14             ` Xavier Toth
2008-01-15 22:47               ` Eamon Walsh
2008-01-16 15:41                 ` Xavier Toth
2008-01-16 16:05                   ` Xavier Toth
     [not found] <195F0BAA-7896-416C-9897-E191080161D4@nall.com>
     [not found] ` <47EC1760.7050504@tycho.nsa.gov>
     [not found]   ` <F3CB74C1-A379-4B76-A41B-E7282D0C580A@nall.com>
2008-06-30 19:38     ` Eamon Walsh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47867FCA.50408@tycho.nsa.gov \
    --to=ewalsh@tycho.nsa.gov \
    --cc=Glenn.Faden@sun.com \
    --cc=selinux@tycho.nsa.gov \
    --cc=txtoth@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.