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