X avcs

X avcs

[Xavier Toth]

swo_u who is running ranged (systemlow-systemhigh) uses newrole to
launch an X windows app at systemhigh and then I get avcs like the
following:

avc:  denied  { receive } for request=X11:ChangeWindowAttributes
comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
avc:  denied  { get_property } for request=X11:GetProperty
comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
event=X11:MapNotify scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
tcontext=swo_u:object_r:user_manage_xevent_t:s15:c0.c1023
tclass=x_event
avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
event=X11:VisibilityNotify
scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
tcontext=swo_u:object_r:user_default_xevent_t:s15:c0.c1023
tclass=x_event
avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
event=X11:PropertyNotify scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
tcontext=swo_u:object_r:user_property_xevent_t:s15:c0.c1023
tclass=x_event
avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
event=X11:FocusIn scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
tcontext=swo_u:object_r:user_focus_xevent_t:s15:c0.c1023
tclass=x_event
avc:  denied  { getattr } for request=X11:GetGeometry
comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
avc:  denied  { read } for request=X11:GetProperty
comm=/usr/libexec/notification-daemon property=WM_NAME
scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
tcontext=swo_u:object_r:user_default_xproperty_t:s15:c0.c1023
tclass=x_property

I'm not familiar with /usr/libexec/notification-daemon and what it
does and I'm thinking that it's probably not the best idea to use
mls_xwin_read_all_levels for user_t.. Any suggestions?

--
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.

Re: X avcs

[Xavier Toth]

What about labeling notification-daemon as other gnome apps have been
labeled (user_xpriv_t)?

On Dec 26, 2007 3:01 PM, Xavier Toth <txtoth@gmail.com> wrote:
> swo_u who is running ranged (systemlow-systemhigh) uses newrole to
> launch an X windows app at systemhigh and then I get avcs like the
> following:
>
> avc:  denied  { receive } for request=X11:ChangeWindowAttributes
> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
> avc:  denied  { get_property } for request=X11:GetProperty
> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> event=X11:MapNotify scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> tcontext=swo_u:object_r:user_manage_xevent_t:s15:c0.c1023
> tclass=x_event
> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> event=X11:VisibilityNotify
> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> tcontext=swo_u:object_r:user_default_xevent_t:s15:c0.c1023
> tclass=x_event
> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> event=X11:PropertyNotify scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> tcontext=swo_u:object_r:user_property_xevent_t:s15:c0.c1023
> tclass=x_event
> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> event=X11:FocusIn scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> tcontext=swo_u:object_r:user_focus_xevent_t:s15:c0.c1023
> tclass=x_event
> avc:  denied  { getattr } for request=X11:GetGeometry
> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
> avc:  denied  { read } for request=X11:GetProperty
> comm=/usr/libexec/notification-daemon property=WM_NAME
> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> tcontext=swo_u:object_r:user_default_xproperty_t:s15:c0.c1023
> tclass=x_property
>
> I'm not familiar with /usr/libexec/notification-daemon and what it
> does and I'm thinking that it's probably not the best idea to use
> mls_xwin_read_all_levels for user_t.. Any suggestions?
>

--
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.

Re: X avcs

[Eamon Walsh]

Xavier Toth wrote:
> What about labeling notification-daemon as other gnome apps have been
> labeled (user_xpriv_t)?
>
> On Dec 26, 2007 3:01 PM, Xavier Toth <txtoth@gmail.com> wrote:
>   
>> swo_u who is running ranged (systemlow-systemhigh) uses newrole to
>> launch an X windows app at systemhigh and then I get avcs like the
>> following:
>>
>> avc:  denied  { receive } for request=X11:ChangeWindowAttributes
>> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
>> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
>> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
>> avc:  denied  { get_property } for request=X11:GetProperty
>> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
>> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
>> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
>> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
>> event=X11:MapNotify scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
>> tcontext=swo_u:object_r:user_manage_xevent_t:s15:c0.c1023
>> tclass=x_event
>> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
>> event=X11:VisibilityNotify
>> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
>> tcontext=swo_u:object_r:user_default_xevent_t:s15:c0.c1023
>> tclass=x_event
>> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
>> event=X11:PropertyNotify scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
>> tcontext=swo_u:object_r:user_property_xevent_t:s15:c0.c1023
>> tclass=x_event
>> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
>> event=X11:FocusIn scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
>> tcontext=swo_u:object_r:user_focus_xevent_t:s15:c0.c1023
>> tclass=x_event
>> avc:  denied  { getattr } for request=X11:GetGeometry
>> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
>> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
>> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
>> avc:  denied  { read } for request=X11:GetProperty
>> comm=/usr/libexec/notification-daemon property=WM_NAME
>> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
>> tcontext=swo_u:object_r:user_default_xproperty_t:s15:c0.c1023
>> tclass=x_property
>>     

These are all allowed by the TE rules.  So I think this is a MLS issue.

I committed read-to-clearance and write-to-clearance interfaces and went 
ahead and granted read-to-clearance in the per-role template.  The patch 
I committed is below.  So update from SVN and see if that solves the 
problem.

Index: policy/modules/kernel/mls.if
===================================================================
--- policy/modules/kernel/mls.if	(revision 2565)
+++ policy/modules/kernel/mls.if	(working copy)
@@ -612,6 +612,26 @@
 ########################################
 ## <summary>
 ##	Make specified domain MLS trusted
+##	for reading from X objects up to its clearance.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`mls_xwin_read_to_clearance',`
+	gen_require(`
+		attribute mlsxwinreadtoclr;
+	')
+
+	typeattribute $1 mlsxwinreadtoclr;
+')
+
+########################################
+## <summary>
+##	Make specified domain MLS trusted
 ##	for reading from X objects at any level.
 ## </summary>
 ## <param name="domain">
@@ -632,6 +652,26 @@
 ########################################
 ## <summary>
 ##	Make specified domain MLS trusted
+##	for write to X objects up to its clearance.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`mls_xwin_write_to_clearance',`
+	gen_require(`
+		attribute mlsxwinwritetoclr;
+	')
+
+	typeattribute $1 mlsxwinwritetoclr;
+')
+
+########################################
+## <summary>
+##	Make specified domain MLS trusted
 ##	for writing to X objects at any level.
 ## </summary>
 ## <param name="domain">
Index: policy/modules/services/xwindows.if
===================================================================
--- policy/modules/services/xwindows.if	(revision 2565)
+++ policy/modules/services/xwindows.if	(working copy)
@@ -374,6 +374,7 @@
 	#
 
 	xwindows_domain_template($1,$1,$2,$3)
+	mls_xwin_read_to_clearance($2)
 
 	# FIXME: this domain should be removed
 	xwindows_domain_template($1,$1_xpriv,$1_xpriv_t,$3)



-- 
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.

Re: X avcs

[Xavier Toth]

Thanks I'll check it out.

On Dec 28, 2007 1:34 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>
> Xavier Toth wrote:
> > What about labeling notification-daemon as other gnome apps have been
> > labeled (user_xpriv_t)?
> >
> > On Dec 26, 2007 3:01 PM, Xavier Toth <txtoth@gmail.com> wrote:
> >
> >> swo_u who is running ranged (systemlow-systemhigh) uses newrole to
> >> launch an X windows app at systemhigh and then I get avcs like the
> >> following:
> >>
> >> avc:  denied  { receive } for request=X11:ChangeWindowAttributes
> >> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
> >> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> >> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
> >> avc:  denied  { get_property } for request=X11:GetProperty
> >> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
> >> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> >> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
> >> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> >> event=X11:MapNotify scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> >> tcontext=swo_u:object_r:user_manage_xevent_t:s15:c0.c1023
> >> tclass=x_event
> >> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> >> event=X11:VisibilityNotify
> >> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> >> tcontext=swo_u:object_r:user_default_xevent_t:s15:c0.c1023
> >> tclass=x_event
> >> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> >> event=X11:PropertyNotify scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> >> tcontext=swo_u:object_r:user_property_xevent_t:s15:c0.c1023
> >> tclass=x_event
> >> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> >> event=X11:FocusIn scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> >> tcontext=swo_u:object_r:user_focus_xevent_t:s15:c0.c1023
> >> tclass=x_event
> >> avc:  denied  { getattr } for request=X11:GetGeometry
> >> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
> >> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> >> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
> >> avc:  denied  { read } for request=X11:GetProperty
> >> comm=/usr/libexec/notification-daemon property=WM_NAME
> >> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> >> tcontext=swo_u:object_r:user_default_xproperty_t:s15:c0.c1023
> >> tclass=x_property
> >>
>
> These are all allowed by the TE rules.  So I think this is a MLS issue.
>
> I committed read-to-clearance and write-to-clearance interfaces and went
> ahead and granted read-to-clearance in the per-role template.  The patch
> I committed is below.  So update from SVN and see if that solves the
> problem.
>
> Index: policy/modules/kernel/mls.if
> ===================================================================
> --- policy/modules/kernel/mls.if        (revision 2565)
> +++ policy/modules/kernel/mls.if        (working copy)
> @@ -612,6 +612,26 @@
>  ########################################
>  ## <summary>
>  ##     Make specified domain MLS trusted
> +##     for reading from X objects up to its clearance.
> +## </summary>
> +## <param name="domain">
> +##     <summary>
> +##     Domain allowed access.
> +##     </summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`mls_xwin_read_to_clearance',`
> +       gen_require(`
> +               attribute mlsxwinreadtoclr;
> +       ')
> +
> +       typeattribute $1 mlsxwinreadtoclr;
> +')
> +
> +########################################
> +## <summary>
> +##     Make specified domain MLS trusted
>  ##     for reading from X objects at any level.
>  ## </summary>
>  ## <param name="domain">
> @@ -632,6 +652,26 @@
>  ########################################
>  ## <summary>
>  ##     Make specified domain MLS trusted
> +##     for write to X objects up to its clearance.
> +## </summary>
> +## <param name="domain">
> +##     <summary>
> +##     Domain allowed access.
> +##     </summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`mls_xwin_write_to_clearance',`
> +       gen_require(`
> +               attribute mlsxwinwritetoclr;
> +       ')
> +
> +       typeattribute $1 mlsxwinwritetoclr;
> +')
> +
> +########################################
> +## <summary>
> +##     Make specified domain MLS trusted
>  ##     for writing to X objects at any level.
>  ## </summary>
>  ## <param name="domain">
> Index: policy/modules/services/xwindows.if
> ===================================================================
> --- policy/modules/services/xwindows.if (revision 2565)
> +++ policy/modules/services/xwindows.if (working copy)
> @@ -374,6 +374,7 @@
>         #
>
>         xwindows_domain_template($1,$1,$2,$3)
> +       mls_xwin_read_to_clearance($2)
>
>         # FIXME: this domain should be removed
>         xwindows_domain_template($1,$1_xpriv,$1_xpriv_t,$3)
>
>
>
> --
> 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.

Re: X avcs

[Xavier Toth]

Ok that helped the issue with the notification-daemon. Now I'm looking
at some avcs generated while running one of our apps and have some
more questions. I first ran QBrowser at CONFIDENTIAL(s2:c0.c253) then
later ran it at TS(s4:c0.c253). CUT_BUFFER0 and _MOTIF_DRAG_TARGETS
got created at CONFIDENTIAL and then the TS instance of the app tried
to use them, do we need polyinstantiated properties? Or maybe the type
should change on write.

avc:  denied  { write } for request=X11:ChangeProperty
comm=/opt/jcdx/bin/QBrowser property=CUT_BUFFER0
scontext=swo_u:user_r:user_t:s4:c0.c253
tcontext=swo_u:object_r:clipboard_xproperty_t:s2:c0.c253
tclass=x_property
avc:  denied  { write } for request=X11:ChangeProperty
comm=/opt/jcdx/bin/QBrowser property=_MOTIF_DRAG_TARGETS
scontext=swo_u:user_r:user_t:s4:c0.c253
tcontext=swo_u:object_r:user_default_xproperty_t:s2:c0.c253
tclass=x_property

Why are the root window drawable and root color map s0?

avc:  denied  { send } for request=X11:SendEvent
comm=/opt/jcdx/bin/QBrowser resid=76 restype=WINDOW
scontext=swo_u:user_r:user_t:s4:c0.c253
tcontext=system_u:object_r:x_rootwindow_t:s0 tclass=x_drawable
avc:  denied  { remove_color } for request=X11:FreeColors
comm=/opt/jcdx/bin/QBrowser resid=20 restype=COLORMAP
scontext=swo_u:user_r:user_t:s4:c0.c253
tcontext=system_u:object_r:x_rootcolormap_t:s0 tclass=x_colormap

On Dec 28, 2007 3:26 PM, Xavier Toth <txtoth@gmail.com> wrote:
> Thanks I'll check it out.
>
>
> On Dec 28, 2007 1:34 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> >
> > Xavier Toth wrote:
> > > What about labeling notification-daemon as other gnome apps have been
> > > labeled (user_xpriv_t)?
> > >
> > > On Dec 26, 2007 3:01 PM, Xavier Toth <txtoth@gmail.com> wrote:
> > >
> > >> swo_u who is running ranged (systemlow-systemhigh) uses newrole to
> > >> launch an X windows app at systemhigh and then I get avcs like the
> > >> following:
> > >>
> > >> avc:  denied  { receive } for request=X11:ChangeWindowAttributes
> > >> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
> > >> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> > >> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
> > >> avc:  denied  { get_property } for request=X11:GetProperty
> > >> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
> > >> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> > >> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
> > >> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> > >> event=X11:MapNotify scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> > >> tcontext=swo_u:object_r:user_manage_xevent_t:s15:c0.c1023
> > >> tclass=x_event
> > >> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> > >> event=X11:VisibilityNotify
> > >> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> > >> tcontext=swo_u:object_r:user_default_xevent_t:s15:c0.c1023
> > >> tclass=x_event
> > >> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> > >> event=X11:PropertyNotify scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> > >> tcontext=swo_u:object_r:user_property_xevent_t:s15:c0.c1023
> > >> tclass=x_event
> > >> avc:  denied  { receive } for  comm=/usr/libexec/notification-daemon
> > >> event=X11:FocusIn scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> > >> tcontext=swo_u:object_r:user_focus_xevent_t:s15:c0.c1023
> > >> tclass=x_event
> > >> avc:  denied  { getattr } for request=X11:GetGeometry
> > >> comm=/usr/libexec/notification-daemon resid=3800036 restype=WINDOW
> > >> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> > >> tcontext=swo_u:object_r:user_t:s15:c0.c1023 tclass=x_drawable
> > >> avc:  denied  { read } for request=X11:GetProperty
> > >> comm=/usr/libexec/notification-daemon property=WM_NAME
> > >> scontext=swo_u:user_r:user_t:s0-s15:c0.c1023
> > >> tcontext=swo_u:object_r:user_default_xproperty_t:s15:c0.c1023
> > >> tclass=x_property
> > >>
> >
> > These are all allowed by the TE rules.  So I think this is a MLS issue.
> >
> > I committed read-to-clearance and write-to-clearance interfaces and went
> > ahead and granted read-to-clearance in the per-role template.  The patch
> > I committed is below.  So update from SVN and see if that solves the
> > problem.
> >
> > Index: policy/modules/kernel/mls.if
> > ===================================================================
> > --- policy/modules/kernel/mls.if        (revision 2565)
> > +++ policy/modules/kernel/mls.if        (working copy)
> > @@ -612,6 +612,26 @@
> >  ########################################
> >  ## <summary>
> >  ##     Make specified domain MLS trusted
> > +##     for reading from X objects up to its clearance.
> > +## </summary>
> > +## <param name="domain">
> > +##     <summary>
> > +##     Domain allowed access.
> > +##     </summary>
> > +## </param>
> > +## <rolecap/>
> > +#
> > +interface(`mls_xwin_read_to_clearance',`
> > +       gen_require(`
> > +               attribute mlsxwinreadtoclr;
> > +       ')
> > +
> > +       typeattribute $1 mlsxwinreadtoclr;
> > +')
> > +
> > +########################################
> > +## <summary>
> > +##     Make specified domain MLS trusted
> >  ##     for reading from X objects at any level.
> >  ## </summary>
> >  ## <param name="domain">
> > @@ -632,6 +652,26 @@
> >  ########################################
> >  ## <summary>
> >  ##     Make specified domain MLS trusted
> > +##     for write to X objects up to its clearance.
> > +## </summary>
> > +## <param name="domain">
> > +##     <summary>
> > +##     Domain allowed access.
> > +##     </summary>
> > +## </param>
> > +## <rolecap/>
> > +#
> > +interface(`mls_xwin_write_to_clearance',`
> > +       gen_require(`
> > +               attribute mlsxwinwritetoclr;
> > +       ')
> > +
> > +       typeattribute $1 mlsxwinwritetoclr;
> > +')
> > +
> > +########################################
> > +## <summary>
> > +##     Make specified domain MLS trusted
> >  ##     for writing to X objects at any level.
> >  ## </summary>
> >  ## <param name="domain">
> > Index: policy/modules/services/xwindows.if
> > ===================================================================
> > --- policy/modules/services/xwindows.if (revision 2565)
> > +++ policy/modules/services/xwindows.if (working copy)
> > @@ -374,6 +374,7 @@
> >         #
> >
> >         xwindows_domain_template($1,$1,$2,$3)
> > +       mls_xwin_read_to_clearance($2)
> >
> >         # FIXME: this domain should be removed
> >         xwindows_domain_template($1,$1_xpriv,$1_xpriv_t,$3)
> >
> >
> >
> > --
> > 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.

Re: X avcs

[Glenn Faden]

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.

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.

--Glenn


Xavier Toth wrote:
> Ok that helped the issue with the notification-daemon. Now I'm looking
> at some avcs generated while running one of our apps and have some
> more questions. I first ran QBrowser at CONFIDENTIAL(s2:c0.c253) then
> later ran it at TS(s4:c0.c253). CUT_BUFFER0 and _MOTIF_DRAG_TARGETS
> got created at CONFIDENTIAL and then the TS instance of the app tried
> to use them, do we need polyinstantiated properties? Or maybe the type
> should change on write.
>
> avc:  denied  { write } for request=X11:ChangeProperty
> comm=/opt/jcdx/bin/QBrowser property=CUT_BUFFER0
> scontext=swo_u:user_r:user_t:s4:c0.c253
> tcontext=swo_u:object_r:clipboard_xproperty_t:s2:c0.c253
> tclass=x_property
> avc:  denied  { write } for request=X11:ChangeProperty
> comm=/opt/jcdx/bin/QBrowser property=_MOTIF_DRAG_TARGETS
> scontext=swo_u:user_r:user_t:s4:c0.c253
> tcontext=swo_u:object_r:user_default_xproperty_t:s2:c0.c253
> tclass=x_property
>
> Why are the root window drawable and root color map s0?
>
> avc:  denied  { send } for request=X11:SendEvent
> comm=/opt/jcdx/bin/QBrowser resid=76 restype=WINDOW
> scontext=swo_u:user_r:user_t:s4:c0.c253
> tcontext=system_u:object_r:x_rootwindow_t:s0 tclass=x_drawable
> avc:  denied  { remove_color } for request=X11:FreeColors
> comm=/opt/jcdx/bin/QBrowser resid=20 restype=COLORMAP
> scontext=swo_u:user_r:user_t:s4:c0.c253
> tcontext=system_u:object_r:x_rootcolormap_t:s0 tclass=x_colormap
>
>   


--
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.

Re: X avcs

[Ted X Toth]

Currently the root window drawable is labeled s0 which is system low but 
it seems like it should be system high (s15:c0.c1023).

As for polyinstantiating properties I've been looking at dix property, 
xace and xselinux and thinking about how it could be done. Looking at 
property.c it seems like FindProperty would be the logical place to 
search for properties based on name, context and probably a list of 
singleton root window properties (as Glenn mentions). Currently 
FindProperty doesn't use XaceHook and it is unclear whether 
XACE_PROPERTY_ACCESS would be the right hook. Also other functions, 
ProcGetProperty, don't use FindProperty to find properties.
Regarding the idea of setting the context when a property is written 
this would only be feasible when the mode was PropModeReplace. Even if 
this were deemed a reasonable approach there'd probably still be a list 
of singleton root window properties that writers could not change the 
context of.
We really need a solution to the issue of polyinstantiated properties or 
there is no way X apps will run in MLS enforcing mode.

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.
>
> 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.
>
> --Glenn
>
>
> Xavier Toth wrote:
>> Ok that helped the issue with the notification-daemon. Now I'm looking
>> at some avcs generated while running one of our apps and have some
>> more questions. I first ran QBrowser at CONFIDENTIAL(s2:c0.c253) then
>> later ran it at TS(s4:c0.c253). CUT_BUFFER0 and _MOTIF_DRAG_TARGETS
>> got created at CONFIDENTIAL and then the TS instance of the app tried
>> to use them, do we need polyinstantiated properties? Or maybe the type
>> should change on write.
>>
>> avc:  denied  { write } for request=X11:ChangeProperty
>> comm=/opt/jcdx/bin/QBrowser property=CUT_BUFFER0
>> scontext=swo_u:user_r:user_t:s4:c0.c253
>> tcontext=swo_u:object_r:clipboard_xproperty_t:s2:c0.c253
>> tclass=x_property
>> avc:  denied  { write } for request=X11:ChangeProperty
>> comm=/opt/jcdx/bin/QBrowser property=_MOTIF_DRAG_TARGETS
>> scontext=swo_u:user_r:user_t:s4:c0.c253
>> tcontext=swo_u:object_r:user_default_xproperty_t:s2:c0.c253
>> tclass=x_property
>>
>> Why are the root window drawable and root color map s0?
>>
>> avc:  denied  { send } for request=X11:SendEvent
>> comm=/opt/jcdx/bin/QBrowser resid=76 restype=WINDOW
>> scontext=swo_u:user_r:user_t:s4:c0.c253
>> tcontext=system_u:object_r:x_rootwindow_t:s0 tclass=x_drawable
>> avc:  denied  { remove_color } for request=X11:FreeColors
>> comm=/opt/jcdx/bin/QBrowser resid=20 restype=COLORMAP
>> scontext=swo_u:user_r:user_t:s4:c0.c253
>> tcontext=system_u:object_r:x_rootcolormap_t:s0 tclass=x_colormap
>>
>>   
>
>


--
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.

Re: X avcs

[Glenn Faden]

Ted X Toth wrote:
> Currently the root window drawable is labeled s0 which is system low 
> but it seems like it should be system high (s15:c0.c1023).

We treat it as system low to make screen snapshots and animations work 
properly. It also provides better integrity. Why should it be system high?

I think you want to make a distinction between the root drawable (as a 
viewable image) and as a conduit for event notification. In our 
implementation the drawable is system low, but the label for sending 
events to the root window is essentially system high. Anyone can send an 
event to the root window, but these events are only delivered to TCB 
clients. The ability to express interest in such events is restricted.

We also have a fairly complex policy on labeling the root colormap in 
which each color cell is independently labeled. This is an artifact of 
the graphics hardware we supported (8bit color maps).

>
> As for polyinstantiating properties I've been looking at dix property, 
> xace and xselinux and thinking about how it could be done. Looking at 
> property.c it seems like FindProperty would be the logical place to 
> search for properties based on name, context and probably a list of 
> singleton root window properties (as Glenn mentions). Currently 
> FindProperty doesn't use XaceHook and it is unclear whether 
> XACE_PROPERTY_ACCESS would be the right hook. Also other functions, 
> ProcGetProperty, don't use FindProperty to find properties.
> Regarding the idea of setting the context when a property is written 
> this would only be feasible when the mode was PropModeReplace. Even if 
> this were deemed a reasonable approach there'd probably still be a 
> list of singleton root window properties that writers could not change 
> the context of.
> We really need a solution to the issue of polyinstantiated properties 
> or there is no way X apps will run in MLS enforcing mode.
>
We implemented this before XACE was developed. I think a new hook is 
required.

--Glenn

--
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.

Re: X avcs

[Eamon Walsh]

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.

Re: X avcs

[Eamon Walsh]

Glenn Faden wrote:
> Ted X Toth wrote:
>   
>> Currently the root window drawable is labeled s0 which is system low 
>> but it seems like it should be system high (s15:c0.c1023).
>>     
>
> We treat it as system low to make screen snapshots and animations work 
> properly. It also provides better integrity. Why should it be system high?
>
> I think you want to make a distinction between the root drawable (as a 
> viewable image) and as a conduit for event notification. In our 
> implementation the drawable is system low, but the label for sending 
> events to the root window is essentially system high. Anyone can send an 
> event to the root window, but these events are only delivered to TCB 
> clients. The ability to express interest in such events is restricted.
>   

I have to think about this some more, but currently there is no 
separation between event destination and drawable in the SELinux model - 
they are the same object.  The abiliy to read/write the drawable and 
send/receive events are separate TE permissions.

The contexts on the root window and root colormap are derived through 
type transitions from the context of the X server process.  I think the 
root window probably should be system-high, because without some kind of 
censoring logic, if you can read the contents of a window in X you can 
read all of its children as well.  Screenshot applications and the 
window-manager animations should both be at system-high as well so there 
wouldn't be a problem here, no?

> We also have a fairly complex policy on labeling the root colormap in 
> which each color cell is independently labeled. This is an artifact of 
> the graphics hardware we supported (8bit color maps).
>   

"Requested 84 colors, got 0."  Who can forget those days.  Anyway, the 
original set of X security classes did have a "color" class that was 
intended for individual color cells, however I dropped it in my revision 
because I decided it would be too much work to fully secure the colormap 
implementation given the fact that hardly anything uses indexed-color 
mode anymore, and even things that do can just install their own colormaps.


>   
>> As for polyinstantiating properties I've been looking at dix property, 
>> xace and xselinux and thinking about how it could be done. Looking at 
>> property.c it seems like FindProperty would be the logical place to 
>> search for properties based on name, context and probably a list of 
>> singleton root window properties (as Glenn mentions). Currently 
>> FindProperty doesn't use XaceHook and it is unclear whether 
>> XACE_PROPERTY_ACCESS would be the right hook. Also other functions, 
>> ProcGetProperty, don't use FindProperty to find properties.
>> Regarding the idea of setting the context when a property is written 
>> this would only be feasible when the mode was PropModeReplace. Even if 
>> this were deemed a reasonable approach there'd probably still be a 
>> list of singleton root window properties that writers could not change 
>> the context of.
>> We really need a solution to the issue of polyinstantiated properties 
>> or there is no way X apps will run in MLS enforcing mode.
>>
>>     
> We implemented this before XACE was developed. I think a new hook is 
> required.
>
> --Glenn
>
>   


-- 
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.

Re: X avcs

[Glenn Faden]

Eamon Walsh wrote:
> 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.
"Fixing" applications to work in a secure environment implies that they 
are currently broken. It seems that the policy is broken if it prevents 
commonly used applications from working. Isn't the purpose of policy 
development to improve the safety of existing applications?
> 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.
Certainly the environment should support multilevel applications, but I 
these are exceptions. Virtually all applications should work without 
modification at a single level.

--Glenn

--
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.

Re: X avcs

[Glenn Faden]

Eamon Walsh wrote:
> Glenn Faden wrote:
>>
>> We treat it as system low to make screen snapshots and animations 
>> work properly. It also provides better integrity. Why should it be 
>> system high?
>>
>> I think you want to make a distinction between the root drawable (as 
>> a viewable image) and as a conduit for event notification. In our 
>> implementation the drawable is system low, but the label for sending 
>> events to the root window is essentially system high. Anyone can send 
>> an event to the root window, but these events are only delivered to 
>> TCB clients. The ability to express interest in such events is 
>> restricted.
>>   
>
> I have to think about this some more, but currently there is no 
> separation between event destination and drawable in the SELinux model 
> - they are the same object.  The ability to read/write the drawable 
> and send/receive events are separate TE permissions.
>
> The contexts on the root window and root colormap are derived through 
> type transitions from the context of the X server process.  I think 
> the root window probably should be system-high, because without some 
> kind of censoring logic, if you can read the contents of a window in X 
> you can read all of its children as well.  Screenshot applications and 
> the window-manager animations should both be at system-high as well so 
> there wouldn't be a problem here, no?
The contents of the root window is typically irrelevant. In most modern 
desktops the root window is completely obscured by a desktop window and 
various panel windows. It should not be required to run a screenshot 
applications at system high unless you are trying to dump system high 
pixels. If you allow higher-level windows to overlap lower-level windows 
(as we do), then you must have some kind of censoring logic. In our case 
we blacken any row in which there are any exposed pixels which are not 
dominated by the label of the snapshot application. However, our 
convention of running separately labeled clients in separate workspaces 
permits fullscreen snapshots to be taken at the label of the workspace.
>
>> We also have a fairly complex policy on labeling the root colormap in 
>> which each color cell is independently labeled. This is an artifact 
>> of the graphics hardware we supported (8bit color maps).
>>   
>
> "Requested 84 colors, got 0."  Who can forget those days.  Anyway, the 
> original set of X security classes did have a "color" class that was 
> intended for individual color cells, however I dropped it in my 
> revision because I decided it would be too much work to fully secure 
> the colormap implementation given the fact that hardly anything uses 
> indexed-color mode anymore, and even things that do can just install 
> their own colormaps.
>
You're probably right, but you can use our code if you wish.

--Glenn

--
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.

Re: X avcs

[Ted X Toth]

Eamon Walsh wrote:
> 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.
>
I'll look at implementing a dixPropertyLookup function. Do any other 
XACE hooks have value-return parameters, would it just be va_arg(ap, 
PropertyPtr*)?
What about the idea of an exception list of single-instance root-window 
properties?

>> 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.
>


--
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.

Re: X avcs

[Glenn Faden]

Ted X Toth wrote:
> I'll look at implementing a dixPropertyLookup function. Do any other 
> XACE hooks have value-return parameters, would it just be va_arg(ap, 
> PropertyPtr*)?
> What about the idea of an exception list of single-instance 
> root-window properties?
>
We have already implemented the equivalent of a dixPropertyLookup 
function called PolyProperty. The following URL is an OpenSolaris source 
browser query to find the implementation and uses of that function in Xorg.

http://src.opensolaris.org/source/search?q=&defs=&refs=PolyProperty&path=&hist=&project=%2Ffox

--Glenn

--
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.

Re: X avcs

[Ted X Toth]

Glenn Faden wrote:
> Ted X Toth wrote:
>> I'll look at implementing a dixPropertyLookup function. Do any other 
>> XACE hooks have value-return parameters, would it just be va_arg(ap, 
>> PropertyPtr*)?
>> What about the idea of an exception list of single-instance 
>> root-window properties?
>>
> We have already implemented the equivalent of a dixPropertyLookup 
> function called PolyProperty. The following URL is an OpenSolaris 
> source browser query to find the implementation and uses of that 
> function in Xorg.
>
> http://src.opensolaris.org/source/search?q=&defs=&refs=PolyProperty&path=&hist=&project=%2Ffox 
>
>
> --Glenn
>
I will look at this, thanks.

--
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.

Re: X avcs

[Eamon Walsh]

Ted X Toth wrote:
> I'll look at implementing a dixPropertyLookup function. Do any other 
> XACE hooks have value-return parameters, would it just be va_arg(ap, 
> PropertyPtr*)?
>   

No and yes, respectively.

> What about the idea of an exception list of single-instance root-window 
> properties?
>   

I'm examining the type_member policy statement to determine how we can 
use it to provide this information.  type_member was intented to support 
polyinstantiation but it's mls semantics have not been defined yet.



>   
>>> 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.
>>
>>     
>
>
> --
> 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.
>
>   


-- 
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.

Re: X avcs

[Xavier Toth]

On Jan 10, 2008 2:27 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> 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.
>

Yep, rotate, list, anything that traverses the property list, is a
problem. It seems like it would be better to have a property list per
context. How about a dixLookupProperties function on window that would
return a linked list (PropertyPtr) of properties that it gets from an
xace hook call?

> 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.

Re: X avcs

[Eamon Walsh]

Xavier Toth wrote:
> On Jan 10, 2008 2:27 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>   
>> 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.
>>
>>     
>
> Yep, rotate, list, anything that traverses the property list, is a
> problem. It seems like it would be better to have a property list per
> context. How about a dixLookupProperties function on window that would
> return a linked list (PropertyPtr) of properties that it gets from an
> xace hook call?
>   

It would be a lot of work for security modules to put this list 
together.  I think it would be best to just use the singular 
dixLookupProperty() and modify the list traversal code to use it.  The 
awkward case is ProcListProperty where the lookup function would have to 
be called, and if it returns BadValue that can mean "this PropertyPtr 
doesn't really exist, move along."  But the rotate code already uses 
FindProperty and I think the other cases can be handled without any 
difficulties.


-- 
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.

Re: X avcs

[Xavier Toth]

On Jan 15, 2008 4:47 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>
> Xavier Toth wrote:
> > On Jan 10, 2008 2:27 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> >
> >> 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.
> >>
> >>
> >
> > Yep, rotate, list, anything that traverses the property list, is a
> > problem. It seems like it would be better to have a property list per
> > context. How about a dixLookupProperties function on window that would
> > return a linked list (PropertyPtr) of properties that it gets from an
> > xace hook call?
> >
>
> It would be a lot of work for security modules to put this list
> together.  I think it would be best to just use the singular
> dixLookupProperty() and modify the list traversal code to use it.  The
> awkward case is ProcListProperty where the lookup function would have to
> be called, and if it returns BadValue that can mean "this PropertyPtr
> doesn't really exist, move along."  But the rotate code already uses
> FindProperty and I think the other cases can be handled without any
> difficulties.
>

ProcListProperties can simply build an array of PropertyPtr for
properties successfully returned by dixLookupProperty as follows:

    PropertyPtr *pProps;
    REQUEST(xResourceReq);

    REQUEST_SIZE_MATCH(xResourceReq);
    rc = dixLookupWindow(&pWin, stuff->id, client, DixListPropAccess);
    if (rc != Success)
        return rc;

    pProp = wUserProps (pWin);
    if (pProp)
        if(!(pProps = (PropertyPtr *)xalloc(sizeof(PropertyPtr))))
            return(BadAlloc);

    while (pProp)
    {
        pProp = pProp->next;
        rc = dixLookupProperty(&pProp, pWin, pProp->propertyName, client,
		      DixReadAccess);
	if (pProp && rc == Success) {
	    pProps[numProps] = pProp;
	    numProps++;
	    if(!(pProps = (PropertyPtr *)xrealloc(pProps, (numProps+1) *
sizeof(PropertyPtr))))
	        return(BadAlloc);
	}
    }
    if (numProps)
        if(!(pAtoms = (Atom *)xalloc(numProps * sizeof(Atom))))
            return(BadAlloc);

    xlpr.type = X_Reply;
    xlpr.nProperties = numProps;
    xlpr.length = (numProps * sizeof(Atom)) >> 2;
    xlpr.sequenceNumber = client->sequence;
    temppAtoms = pAtoms;
    for (i = 0; i < numProps; i++)
    {
	*temppAtoms++ = pProps[i]->propertyName;
    }
    WriteReplyToClient(client, sizeof(xGenericReply), &xlpr);
    if (numProps)
    {
        client->pSwapReplyFunc = (ReplySwapPtr)Swap32Write;
        WriteSwappedDataToClient(client, numProps * sizeof(Atom), pAtoms);
        xfree(pAtoms);
	xfree(pProps);
    }

Rotate however is more problematic. How do you rotate when the list is
really multiple lists in one? Maybe I just don't understand the
semantics of rotate??

>
> --
>
> 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.

Re: X avcs

[Xavier Toth]

On Jan 16, 2008 9:41 AM, Xavier Toth <txtoth@gmail.com> wrote:
>
> On Jan 15, 2008 4:47 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> >
> > Xavier Toth wrote:
> > > On Jan 10, 2008 2:27 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> > >
> > >> 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.
> > >>
> > >>
> > >
> > > Yep, rotate, list, anything that traverses the property list, is a
> > > problem. It seems like it would be better to have a property list per
> > > context. How about a dixLookupProperties function on window that would
> > > return a linked list (PropertyPtr) of properties that it gets from an
> > > xace hook call?
> > >
> >
> > It would be a lot of work for security modules to put this list
> > together.  I think it would be best to just use the singular
> > dixLookupProperty() and modify the list traversal code to use it.  The
> > awkward case is ProcListProperty where the lookup function would have to
> > be called, and if it returns BadValue that can mean "this PropertyPtr
> > doesn't really exist, move along."  But the rotate code already uses
> > FindProperty and I think the other cases can be handled without any
> > difficulties.
> >
>
> ProcListProperties can simply build an array of PropertyPtr for
> properties successfully returned by dixLookupProperty as follows:
>
>     PropertyPtr *pProps;
>     REQUEST(xResourceReq);
>
>     REQUEST_SIZE_MATCH(xResourceReq);
>     rc = dixLookupWindow(&pWin, stuff->id, client, DixListPropAccess);
>     if (rc != Success)
>         return rc;
>
>     pProp = wUserProps (pWin);
>     if (pProp)
>         if(!(pProps = (PropertyPtr *)xalloc(sizeof(PropertyPtr))))
>             return(BadAlloc);
>
>     while (pProp)
>     {
>         pProp = pProp->next;
>         rc = dixLookupProperty(&pProp, pWin, pProp->propertyName, client,
>                       DixReadAccess);
>         if (pProp && rc == Success) {

oops..  there needs to be additional logic here to ensure uniqueness
of pProp within pProps

>             pProps[numProps] = pProp;
>             numProps++;
>             if(!(pProps = (PropertyPtr *)xrealloc(pProps, (numProps+1) *
> sizeof(PropertyPtr))))
>                 return(BadAlloc);
>         }
>     }
>     if (numProps)
>         if(!(pAtoms = (Atom *)xalloc(numProps * sizeof(Atom))))
>             return(BadAlloc);
>
>     xlpr.type = X_Reply;
>     xlpr.nProperties = numProps;
>     xlpr.length = (numProps * sizeof(Atom)) >> 2;
>     xlpr.sequenceNumber = client->sequence;
>     temppAtoms = pAtoms;
>     for (i = 0; i < numProps; i++)
>     {
>         *temppAtoms++ = pProps[i]->propertyName;
>     }
>     WriteReplyToClient(client, sizeof(xGenericReply), &xlpr);
>     if (numProps)
>     {
>         client->pSwapReplyFunc = (ReplySwapPtr)Swap32Write;
>         WriteSwappedDataToClient(client, numProps * sizeof(Atom), pAtoms);
>         xfree(pAtoms);
>         xfree(pProps);
>     }
>
> Rotate however is more problematic. How do you rotate when the list is
> really multiple lists in one? Maybe I just don't understand the
> semantics of rotate??
>
> >
> > --
>
> >
> > 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.

Re: X avcs

[Eamon Walsh]

Glenn Faden wrote:
> Ted X Toth wrote:
>   
>> I'll look at implementing a dixPropertyLookup function. Do any other 
>> XACE hooks have value-return parameters, would it just be va_arg(ap, 
>> PropertyPtr*)?
>> What about the idea of an exception list of single-instance 
>> root-window properties?
>>
>>     
> We have already implemented the equivalent of a dixPropertyLookup 
> function called PolyProperty. The following URL is an OpenSolaris source 
> browser query to find the implementation and uses of that function in Xorg.
>
> http://src.opensolaris.org/source/search?q=&defs=&refs=PolyProperty&path=&hist=&project=%2Ffox
>
> --Glenn
>   

OK, I worked on this today.  The property polyinstantiation itself is 
easy enough, but I've run into a problem with the PropertyNotify events 
that occur when a polyinstantiated property is changed or deleted - 
everyone can see them!  Some major changes to the event delivery model 
are probably going to be necessary to make this work.

I can't immediately see how it's done in Trusted Extensions.  In 
TsolDeleteProperty there is just a regular DeliverEvents call to send 
the event.

I think there will have to be a way to pass some private data down with 
all events, and then have another hook call further down that gives a 
yes/no answer for each client.


-- 
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.

Re: X avcs

[Glenn Faden]

Eamon Walsh wrote:
>  
> OK, I worked on this today.  The property polyinstantiation itself is 
> easy enough, but I've run into a problem with the PropertyNotify 
> events that occur when a polyinstantiated property is changed or 
> deleted - everyone can see them!  Some major changes to the event 
> delivery model are probably going to be necessary to make this work.
>
> I can't immediately see how it's done in Trusted Extensions.  In 
> TsolDeleteProperty there is just a regular DeliverEvents call to send 
> the event.
>
> I think there will have to be a way to pass some private data down 
> with all events, and then have another hook call further down that 
> gives a yes/no answer for each client.
You're probably right that unnecessary PropertyNotify events may be 
distributed to any client who has expressed interest in this event on 
the root window. I don't think this is a big problem, however. If the 
client cares to read the property whose atom is associated with the 
event it will get the value which matches its security context.

If your concern is that this presents a covert channel, that is an issue 
that we generally ignore. For example we don't prevent higher-level 
windows from generating exposure events which may be delivered to lower 
level windows. We only prevent normal clients from mapping windows into 
a Trusted Path workspace.

--Glenn

--
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.

Re: X avcs

[Eamon Walsh]

Glenn Faden wrote:
> Eamon Walsh wrote:
>   
>>  
>> OK, I worked on this today.  The property polyinstantiation itself is 
>> easy enough, but I've run into a problem with the PropertyNotify 
>> events that occur when a polyinstantiated property is changed or 
>> deleted - everyone can see them!  Some major changes to the event 
>> delivery model are probably going to be necessary to make this work.
>>
>> I can't immediately see how it's done in Trusted Extensions.  In 
>> TsolDeleteProperty there is just a regular DeliverEvents call to send 
>> the event.
>>
>> I think there will have to be a way to pass some private data down 
>> with all events, and then have another hook call further down that 
>> gives a yes/no answer for each client.
>>     
> You're probably right that unnecessary PropertyNotify events may be 
> distributed to any client who has expressed interest in this event on 
> the root window. I don't think this is a big problem, however. If the 
> client cares to read the property whose atom is associated with the 
> event it will get the value which matches its security context.
>
> If your concern is that this presents a covert channel, that is an issue 
> that we generally ignore. For example we don't prevent higher-level 
> windows from generating exposure events which may be delivered to lower 
> level windows. We only prevent normal clients from mapping windows into 
> a Trusted Path workspace.
>
> --Glenn
>   

I'll press forward with this then, putting the event delivery on the 
to-do list.


-- 
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.

Re: X avcs

[Xavier Toth]

Great if you could give us a heads up when it gets into the git tree
I'd appreciate it. Also you previously mentioned that the selinux
module would be in rawhide xserver soon and I'd like to know when that
happens.

On Jan 23, 2008 6:11 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>
> Glenn Faden wrote:
> > Eamon Walsh wrote:
> >
> >>
> >> OK, I worked on this today.  The property polyinstantiation itself is
> >> easy enough, but I've run into a problem with the PropertyNotify
> >> events that occur when a polyinstantiated property is changed or
> >> deleted - everyone can see them!  Some major changes to the event
> >> delivery model are probably going to be necessary to make this work.
> >>
> >> I can't immediately see how it's done in Trusted Extensions.  In
> >> TsolDeleteProperty there is just a regular DeliverEvents call to send
> >> the event.
> >>
> >> I think there will have to be a way to pass some private data down
> >> with all events, and then have another hook call further down that
> >> gives a yes/no answer for each client.
> >>
> > You're probably right that unnecessary PropertyNotify events may be
> > distributed to any client who has expressed interest in this event on
> > the root window. I don't think this is a big problem, however. If the
> > client cares to read the property whose atom is associated with the
> > event it will get the value which matches its security context.
> >
> > If your concern is that this presents a covert channel, that is an issue
> > that we generally ignore. For example we don't prevent higher-level
> > windows from generating exposure events which may be delivered to lower
> > level windows. We only prevent normal clients from mapping windows into
> > a Trusted Path workspace.
> >
> > --Glenn
> >
>
> I'll press forward with this then, putting the event delivery on the
> to-do list.
>
>
>
> --
> 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.

Re: X avcs

[Xavier Toth]

Has this made it into the git tree yet?

On Jan 23, 2008 6:11 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>
> Glenn Faden wrote:
> > Eamon Walsh wrote:
> >
> >>
> >> OK, I worked on this today.  The property polyinstantiation itself is
> >> easy enough, but I've run into a problem with the PropertyNotify
> >> events that occur when a polyinstantiated property is changed or
> >> deleted - everyone can see them!  Some major changes to the event
> >> delivery model are probably going to be necessary to make this work.
> >>
> >> I can't immediately see how it's done in Trusted Extensions.  In
> >> TsolDeleteProperty there is just a regular DeliverEvents call to send
> >> the event.
> >>
> >> I think there will have to be a way to pass some private data down
> >> with all events, and then have another hook call further down that
> >> gives a yes/no answer for each client.
> >>
> > You're probably right that unnecessary PropertyNotify events may be
> > distributed to any client who has expressed interest in this event on
> > the root window. I don't think this is a big problem, however. If the
> > client cares to read the property whose atom is associated with the
> > event it will get the value which matches its security context.
> >
> > If your concern is that this presents a covert channel, that is an issue
> > that we generally ignore. For example we don't prevent higher-level
> > windows from generating exposure events which may be delivered to lower
> > level windows. We only prevent normal clients from mapping windows into
> > a Trusted Path workspace.
> >
> > --Glenn
> >
>
> I'll press forward with this then, putting the event delivery on the
> to-do list.
>
>
>
> --
> 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.

Re: X avcs

[Eamon Walsh]

Xavier Toth wrote:
> Has this made it into the git tree yet?
>   

I am running the compliance tests on it.  I will post the patch on the 
Xorg list for review this week.

I also need to make some changes to libselinux so the x_contexts file 
can contain the list of properties to polyinstantiate.  That will also 
be posted this week.

And finally, you're going to need to build a newer kernel, or backport 
the following short patch to an older kernel:
http://marc.info/?l=selinux&m=120120674815507&w=2


> On Jan 23, 2008 6:11 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>   
>> Glenn Faden wrote:
>>     
>>> Eamon Walsh wrote:
>>>
>>>       
>>>> OK, I worked on this today.  The property polyinstantiation itself is
>>>> easy enough, but I've run into a problem with the PropertyNotify
>>>> events that occur when a polyinstantiated property is changed or
>>>> deleted - everyone can see them!  Some major changes to the event
>>>> delivery model are probably going to be necessary to make this work.
>>>>
>>>> I can't immediately see how it's done in Trusted Extensions.  In
>>>> TsolDeleteProperty there is just a regular DeliverEvents call to send
>>>> the event.
>>>>
>>>> I think there will have to be a way to pass some private data down
>>>> with all events, and then have another hook call further down that
>>>> gives a yes/no answer for each client.
>>>>
>>>>         
>>> You're probably right that unnecessary PropertyNotify events may be
>>> distributed to any client who has expressed interest in this event on
>>> the root window. I don't think this is a big problem, however. If the
>>> client cares to read the property whose atom is associated with the
>>> event it will get the value which matches its security context.
>>>
>>> If your concern is that this presents a covert channel, that is an issue
>>> that we generally ignore. For example we don't prevent higher-level
>>> windows from generating exposure events which may be delivered to lower
>>> level windows. We only prevent normal clients from mapping windows into
>>> a Trusted Path workspace.
>>>
>>> --Glenn
>>>
>>>       
>> I'll press forward with this then, putting the event delivery on the
>> to-do list.
>>
>>
>>
>> --
>> 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.
>
>   


-- 
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.

Re: X avcs

[Eamon Walsh]

Eamon Walsh wrote:
> Xavier Toth wrote:
>   
>> Has this made it into the git tree yet?
>>   

It's pushed into the XACE-SELINUX branch, so you can play with it now.   
I did some simple testing of the polyinstantiation and it worked OK for 
me.  You'll need the kernel patch, an updated libselinux from SVN, and 
an updated refpolicy (or just add "getattr" and "setattr" permissions to 
your x_property class and tweak the x_contexts file to add poly_property 
notations).  I'll push it into the master branch next week unless I get 
any feedback directing otherwise.

With regard to the rawhide X server, I just ran "strings" on a rawhide 
Xorg binary and it shows SELinux extension messages.  The package has a 
date of Jan 7 in the version number.  So you might try compiling an X 
server from SRPM, passing the --enable-xselinux=yes flag to the 
configure script.  It might just work, however there have been some 
changes since Jan 7.

-- 
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.

Re: X avcs

[Xavier Toth]

On Fri, Feb 8, 2008 at 5:51 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Eamon Walsh wrote:
>  > Xavier Toth wrote:
>  >
>  >> Has this made it into the git tree yet?
>  >>
>
>  It's pushed into the XACE-SELINUX branch, so you can play with it now.
>  I did some simple testing of the polyinstantiation and it worked OK for
>  me.  You'll need the kernel patch, an updated libselinux from SVN, and

libselinux from SVN? Is this change not in rawhide?

>  an updated refpolicy (or just add "getattr" and "setattr" permissions to
>  your x_property class and tweak the x_contexts file to add poly_property
>  notations).  I'll push it into the master branch next week unless I get
>  any feedback directing otherwise.
>
>  With regard to the rawhide X server, I just ran "strings" on a rawhide
>  Xorg binary and it shows SELinux extension messages.  The package has a
>  date of Jan 7 in the version number.  So you might try compiling an X
>  server from SRPM, passing the --enable-xselinux=yes flag to the
>  configure script.  It might just work, however there have been some
>  changes since Jan 7.
>
>  --
>
>
> 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.

Re: X avcs

[Xavier Toth]

On Fri, Feb 8, 2008 at 5:51 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Eamon Walsh wrote:
>  > Xavier Toth wrote:
>  >
>  >> Has this made it into the git tree yet?
>  >>
>
>  It's pushed into the XACE-SELINUX branch, so you can play with it now.
>  I did some simple testing of the polyinstantiation and it worked OK for
>  me.  You'll need the kernel patch, an updated libselinux from SVN, and
>  an updated refpolicy (or just add "getattr" and "setattr" permissions to
>  your x_property class and tweak the x_contexts file to add poly_property
>  notations).  I'll push it into the master branch next week unless I get
>  any feedback directing otherwise.

I've been running the rawhide xserver and a patched metacity which
uses the _SELINUX_CLIENT_CONTEXT xproperty to get the context for
window labels. Because of my desire to maintain a working system I've
taken the approach of changing just one thing at a time. So I chose to
update my policy first by merging the refpolicy with the rawhide
source rpm and patch-20071130.patch. After a few issues I've built and
installed the new policy but now metacity is no longer getting a
context in _SELINUX_CLIENT_CONTEXT. I've looked around in the audit
log but nothing jumps out at me as being amiss. Any ideas on how I can
track down why this property was impacted by this new policy?

>
>  With regard to the rawhide X server, I just ran "strings" on a rawhide
>  Xorg binary and it shows SELinux extension messages.  The package has a
>  date of Jan 7 in the version number.  So you might try compiling an X
>  server from SRPM, passing the --enable-xselinux=yes flag to the
>  configure script.  It might just work, however there have been some
>  changes since Jan 7.
>
>  --
>
>
> 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.

Re: X avcs

[Eamon Walsh]

Xavier Toth wrote:
> On Fri, Feb 8, 2008 at 5:51 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>   
>> Eamon Walsh wrote:
>>  > Xavier Toth wrote:
>>  >
>>  >> Has this made it into the git tree yet?
>>  >>
>>
>>  It's pushed into the XACE-SELINUX branch, so you can play with it now.
>>  I did some simple testing of the polyinstantiation and it worked OK for
>>  me.  You'll need the kernel patch, an updated libselinux from SVN, and
>>  an updated refpolicy (or just add "getattr" and "setattr" permissions to
>>  your x_property class and tweak the x_contexts file to add poly_property
>>  notations).  I'll push it into the master branch next week unless I get
>>  any feedback directing otherwise.
>>     
>
> I've been running the rawhide xserver and a patched metacity which
> uses the _SELINUX_CLIENT_CONTEXT xproperty to get the context for
> window labels. Because of my desire to maintain a working system I've
> taken the approach of changing just one thing at a time. So I chose to
> update my policy first by merging the refpolicy with the rawhide
> source rpm and patch-20071130.patch. After a few issues I've built and
> installed the new policy but now metacity is no longer getting a
> context in _SELINUX_CLIENT_CONTEXT. I've looked around in the audit
> log but nothing jumps out at me as being amiss. Any ideas on how I can
> track down why this property was impacted by this new policy?
>   

Look in the Xorg.0.log file for SELinux messages.  The extension might 
have disabled itself, perhaps because the object classes and permissions 
weren't right.

-- 
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.

Re: X avcs

[Eamon Walsh]

Joe Nall wrote:
> On Mar 27, 2008, at 4:53 PM, Eamon Walsh wrote:
>   
>> It's a write-down violation.  Your X server is running at system low  
>> so the root window and root colormap are at system low.  "add child"  
>> is considered a write operation.
>>
>> Have you tried running the X server at SystemHigh?
>>     
>
> Yes. I set up a SystemHigh range transition for X and twm. xinit can't  
> talk to X unless the user level is SystemHigh as well.
>
> type=USER_AVC msg=audit(1214783769.178:696): user pid=21164 uid=500  
> auid=500 ses=5 subj=user_u:user_r:user_xserver_t:s15:c0.c1023  
> msg='avc:  denied  { getattr } for request=X11:CreateGC comm=xinit  
> resid=4c restype=WINDOW scontext=user_u:user_r:user_t:s0  
> tcontext=user_u:object_r:user_rootwindow_t:s15:c0.c1023  
> tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,  
> terminal=tty1)'
> type=USER_AVC msg=audit(1214783769.182:697): user pid=21164 uid=500  
> auid=500 ses=5 subj=user_u:user_r:user_xserver_t:s15:c0.c1023  
> msg='avc:  denied  { get_property } for request=X11:GetProperty  
> comm=xinit resid=4c restype=WINDOW scontext=user_u:user_r:user_t:s0  
> tcontext=user_u:object_r:user_rootwindow_t:s15:c0.c1023  
> tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,  
> terminal=tty1)'
>
> X can't manage its log file from SystemHigh either
>
> type=AVC msg=audit(1214783768.255:680): avc:  denied  { rename } for   
> pid=21164 comm="X" name="Xorg.0.log" dev=dm-0 ino=85120  
> scontext=user_u:user_r:user_xserver_t:s15:c0.c1023  
> tcontext=user_u:object_r:xserver_log_t:s0 tclass=file
> type=AVC msg=audit(1214783768.255:680): avc:  denied  { unlink } for   
> pid=21164 comm="X" name="Xorg.0.log.old" dev=dm-0 ino=85114  
> scontext=user_u:user_r:user_xserver_t:s15:c0.c1023  
> tcontext=user_u:object_r:xserver_log_t:s0 tclass=file
>
> type=AVC msg=audit(1214784233.205:729): avc:  denied  { write } for   
> pid=21225 comm="X" name="log" dev=dm-0 ino=81922  
> scontext=user_u:user_r:user_xserver_t:s15:c0.c1023  
> tcontext=system_u:object_r:var_log_t:s0-s15:c0.c1023 tclass=dir
>
> I'm really struggling to understand the tau of MLS SELinux X (probably  
> because I don't grok X internals yet). What should be level of the  
> rootwindow be? It seems like whether it is SystemHigh or SystemLow,  
> processes at a different level are going to need fairly serious privs  
> to be able to write to the rootwindow.
>   

The mls constraints in refpolicy are probably not correct as they relate 
to the root window.  There has been some discussion of this in an 
earlier thread [1] but no follow up on really sitting down and defining 
the MLS semantics.  The standard categorization of permissions into 
"read" and "write" bins may not be sufficient to adequately describe MLS 
for X window objects.

I'll go through the x_drawable permissions and try to categorize each 
one in terms of MLS:

create
destroy
    Not applicable to the root window, which cannot be created or 
destroyed by user applications.

read
    The problem here is that if you can "read" the contents of a window, 
you can also read the contents of _all_ child windows within it.  This 
means that if you have "read" permission on the root window, you can 
take a screen shot of the entire desktop.  Thus, only processes running 
at SystemHigh should be able to read the root window.

write
    If you can draw into a window, you can also scribble on child 
windows.  Meaning that if you have "write" permission on the root 
window, you can write into any window on the desktop.  Also you could 
spoof windows by simply drawing images into the root window.  So again 
this is a SystemHigh permission.
   
blend
    Blend permission on the root window means that an application is 
attempting to use the Composite extension to redirect the contents of 
the window and its subwindows into a memory buffer for use by the 
application.  This is how compositing managers work.  (The other use 
case of the blend permission, making a window with a transparent 
background, does not apply to the root window because the root window 
always has a solid background).  This is a SystemHigh permission.

getattr
    Normal applications will need to do this.  You should only need 
SystemLow to be able to do this.

setattr
    This permission protects several operations on the root window, 
including setting its background image or background color, setting the 
colormap, and setting the mouse cursor displayed when the cursor is in 
the window.  Only SystemHigh applications should be able to do this.  If 
there is a scenario where a normal application needs this permission, 
then setattr probably needs to be split up into multiple permissions 
depending on what the use case is.

list_child
    This returns the window ID's of all the direct child windows of the 
root window.  This does leak out the number of such windows, which 
client number they belong to, and the stacking order the windows are 
in.  However I don't view this as a major leak, since to find out 
anything additional about a window (besides its ID) you would have to 
make additional protocol requests and go through more access control.  
If you really don't want this leaking out, then only SystemHigh 
applications should be able to do this.  Otherwise SystemLow can do this.

add_child
remove_child
list_property
get_property
   SystemLow should be able to do these.  Everyone needs to create and 
remove windows and read some common properties on the root window.

set_property
    I'm pretty sure that SystemLow will also need the ability to do 
this.  However, window properties could serve as a mechanism for leaking 
data between clients running at different levels.  A client may also be 
able to affect the behavior of other applications by messing with 
property values on the root window.  The various conventions for using 
root window properties need to be examined, and x_contexts labels, 
policy rules, and/or polyinstantiation applied as needed.

manage
override
show
hide
    "manage" permission controls doing window-manager type things like 
moving and resizing the window, reparenting it, raising and lowering 
it.  Override is setting the override-redirect bit on the window.  Show 
and hide are mapping and unmapping the window, respectively.  Like 
create and destroy, none of these permissions are really applicable to 
the root window, since it can't ever be hidden, moved, resized, etc.

send
receive
    Send controls the ability to send events to the root window either 
by using XSendEvent programmatically, or when a device event such as a 
mouse click happens in the root window.  Receive controls the ability to 
register an event mask on the root window, allowing the application to 
receive events that are sent to the root window.  As with properties 
above, allowing this for SystemLow could result in open communications 
between applications at different levels.  However there are certain 
ICCCM conventions that involve regular applications sending an event to 
the root window in order to communicate with the window manager.


[1] http://marc.info/?l=selinux&m=119990105012347&w=2


-- 
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.