X in MLS enforcing problem

X in MLS enforcing problem

[Xavier Toth]

type=AVC msg=audit(1213041678.053:8): avc:  denied  { read } for
pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
tclass=chr_file
type=AVC msg=audit(1213041678.432:10): avc:  denied  { write } for
pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
tclass=chr_file

The xserver_common_domain_template seems to have the necessary allow
rules (dev_read_raw_memory and dev_wx_raw_memory) for the types so  I
create a local module and added:
mls_trusted_object(xdm_xserver_t)
to deal with the MLS constraint violation but I'm still getting these
AVC.What else can it be?

Ted

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: X in MLS enforcing problem

[Chad Hanson]

mls_trusted_object(xdm_xserver_t) won't help this problem, but something
like mls_file_read_up and mls_file_write_down would be more approriate
for xdm_xserver_t.

-Chad

> 
> type=AVC msg=audit(1213041678.053:8): avc:  denied  { read } for
> pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
> scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
> tclass=chr_file
> type=AVC msg=audit(1213041678.432:10): avc:  denied  { write } for
> pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
> scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
> tclass=chr_file
> 
> The xserver_common_domain_template seems to have the necessary allow
> rules (dev_read_raw_memory and dev_wx_raw_memory) for the types so  I
> create a local module and added:
> mls_trusted_object(xdm_xserver_t)
> to deal with the MLS constraint violation but I'm still getting these
> AVC.What else can it be?
> 
> Ted
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: X in MLS enforcing problem

[Xavier Toth]

On Mon, Jun 9, 2008 at 4:49 PM, Chad Hanson <chanson@trustedcs.com> wrote:
>
> mls_trusted_object(xdm_xserver_t) won't help this problem, but something
> like mls_file_read_up and mls_file_write_down would be more approriate
> for xdm_xserver_t.
>
> -Chad
>
>>
>> type=AVC msg=audit(1213041678.053:8): avc:  denied  { read } for
>> pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
>> scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
>> tclass=chr_file
>> type=AVC msg=audit(1213041678.432:10): avc:  denied  { write } for
>> pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
>> scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
>> tclass=chr_file
>>
>> The xserver_common_domain_template seems to have the necessary allow
>> rules (dev_read_raw_memory and dev_wx_raw_memory) for the types so  I
>> create a local module and added:
>> mls_trusted_object(xdm_xserver_t)
>> to deal with the MLS constraint violation but I'm still getting these
>> AVC.What else can it be?
>>
>> Ted
>>
>

Indeed that would only work if the target (the chr_file) were an
mls_trusted_object. So for now I'm using
mls_file_(read/write)_all_levels and those AVCs are handled.

Now I looking at the USER_AVCs and trying to figure out how to
translate those into policy. Will audit2allow be updated to help with
generating rules for the X USER_AVCs?
For those who haven't seen the X user space object manager AVCs here
are some examples:
type=USER_AVC msg=audit(1213049927.142:132): user pid=2636 uid=0
auid=4294967295 ses=4294967295
subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
 { blend } for request=X11:CreateWindow comm=dbus-launch resid=800001
restype=WINDOW scontext=user_u:user_r:user_t:s0
tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1213049927.144:133): user pid=2636 uid=0
auid=4294967295 ses=4294967295
subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
 { setattr } for request=X11:SetSelectionOwner comm=dbus-launch
selection=_DBUS_SESSION_BUS_SELECTION_tedx_caa2282936b539cb3e36c2ae4845ed0b
scontext=user_u:user_r:user_t:s0
tcontext=system_u:object_r:xselection_t:s0 tclass=x_selection :
exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1213049927.227:134): user pid=2636 uid=0
auid=4294967295 ses=4294967295
subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
 { manage } for request=X11:ChangeHosts comm=xhost
scontext=user_u:user_r:user_t:s0
tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
tclass=x_server : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
terminal=?)'
type=USER_AVC msg=audit(1213049927.653:135): user pid=2636 uid=0
auid=4294967295 ses=4294967295
subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
 { blend } for request=X11:CreateWindow comm=gnome-session
resid=800001 restype=WINDOW scontext=user_u:user_r:user_t:s0
tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1213049927.656:136): user pid=2636 uid=0
auid=4294967295 ses=4294967295
subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
 { blend } for request=X11:CreateWindow comm=gnome-session
resid=800002 restype=WINDOW scontext=user_u:user_r:user_t:s0
tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1213049927.659:137): user pid=2636 uid=0
auid=4294967295 ses=4294967295
subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
 { getattr } for request=X11:QueryPointer comm=gnome-session
xdevice="Virtual core pointer" scontext=user_u:user_r:user_t:s0
tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
terminal=?)'
type=USER_AVC msg=audit(1213049927.661:138): user pid=2636 uid=0
auid=4294967295 ses=4294967295
subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
 { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
terminal=?)'
type=USER_AVC msg=audit(1213049927.661:139): user pid=2636 uid=0
auid=4294967295 ses=4294967295
subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
 { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
terminal=?)'
type=USER_AVC msg=audit(1213049927.661:140): user pid=2636 uid=0
auid=4294967295 ses=4294967295
subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
 { getattr setattr } for request=XKEYBOARD:PerClientFlags
comm=gnome-session xdevice="Virtual core keyboard"
scontext=user_u:user_r:user_t:s0
tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
terminal=?)'
type=ANOM_ABEND msg=audit(1213049927.662:141): auid=500 uid=500
gid=500 ses=4 subj=user_u:user_r:user_t:s0 pid=3280
comm="gnome-session" sig=5
type=CRED_DISP msg=audit(1213049927.674:142): user pid=2720 uid=0
auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
msg='op=PAM:setcred acct="tedx" exe="/usr/libexec/gdm-session-worker"
(hostname=?, addr=?, terminal=:0 res=success)'
type=USER_END msg=audit(1213049927.697:143): user pid=2720 uid=0
auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
msg='op=PAM:session_close acct="tedx"
exe="/usr/libexec/gdm-session-worker" (hostname=?, addr=?, terminal=:0
res=success)'

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: X in MLS enforcing problem

[Eamon Walsh]

Xavier Toth wrote:

[snip]

> Now I looking at the USER_AVCs and trying to figure out how to
> translate those into policy. Will audit2allow be updated to help with
> generating rules for the X USER_AVCs?
>   

The stock audit2allow parses my audit.log just fine.  It doesn't work 
for you?


> For those who haven't seen the X user space object manager AVCs here
> are some examples:
> type=USER_AVC msg=audit(1213049927.142:132): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { blend } for request=X11:CreateWindow comm=dbus-launch resid=800001
> restype=WINDOW scontext=user_u:user_r:user_t:s0
> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>   

This is a program attempting to create a window with no background.  The 
denial will cause the window background to be filled in with a solid color.

Dontaudit should work here.

However, window managers do need the blend permission (on all windows).  
The "compositing" feature requires this permission.


> type=USER_AVC msg=audit(1213049927.144:133): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { setattr } for request=X11:SetSelectionOwner comm=dbus-launch
> selection=_DBUS_SESSION_BUS_SELECTION_tedx_caa2282936b539cb3e36c2ae4845ed0b
> scontext=user_u:user_r:user_t:s0
> tcontext=system_u:object_r:xselection_t:s0 tclass=x_selection :
> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>   

This is a known issue.  I have not found an explanation yet for the 
purpose of these D-BUS selections.

There is no easy solution here.  The selabel system cannot handle these 
funky names.  Even if there was regexp support, as Chris has indicated 
the name contains a username, implying that it should be labeled with a 
derived type.

I think the "dbus-launch" program needs to undergo surgery to either not 
create these things or to label them explicitly.


> type=USER_AVC msg=audit(1213049927.227:134): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { manage } for request=X11:ChangeHosts comm=xhost
> scontext=user_u:user_r:user_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tclass=x_server : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
> terminal=?)'
>   

Somewhere in the startup scripts xhost is being called to fiddle with 
the lists of hosts that can connect to the server.

Either solve the xdm_xserver_t versus user_xserver_t problem, which has 
been much discussed, or grant the permission above, and rely on the 
Xauthority mechanism to keep people from running xhost on other people's 
servers.

As to the former, I'm trying to get something working with setcon and my 
GDM/pam_selinux patches.


> type=USER_AVC msg=audit(1213049927.653:135): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { blend } for request=X11:CreateWindow comm=gnome-session
> resid=800001 restype=WINDOW scontext=user_u:user_r:user_t:s0
> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
> type=USER_AVC msg=audit(1213049927.656:136): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { blend } for request=X11:CreateWindow comm=gnome-session
> resid=800002 restype=WINDOW scontext=user_u:user_r:user_t:s0
> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>   

More blend errors.


> type=USER_AVC msg=audit(1213049927.659:137): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { getattr } for request=X11:QueryPointer comm=gnome-session
> xdevice="Virtual core pointer" scontext=user_u:user_r:user_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
> terminal=?)'
>   

The default label for devices is the server's context.  Another xdm / 
user issue.

My GDM/pam_selinux patches attempt to relabel the devices to the user's 
context, the same way the terminal is relabeled when you log in at the 
console.


> type=USER_AVC msg=audit(1213049927.661:138): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
> terminal=?)'
> type=USER_AVC msg=audit(1213049927.661:139): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
> terminal=?)'
> type=USER_AVC msg=audit(1213049927.661:140): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { getattr setattr } for request=XKEYBOARD:PerClientFlags
> comm=gnome-session xdevice="Virtual core keyboard"
> scontext=user_u:user_r:user_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
> terminal=?)'
>   

More device errors.

> type=ANOM_ABEND msg=audit(1213049927.662:141): auid=500 uid=500
> gid=500 ses=4 subj=user_u:user_r:user_t:s0 pid=3280
> comm="gnome-session" sig=5
>   

Standard error handling behavior for the desktop.



> type=CRED_DISP msg=audit(1213049927.674:142): user pid=2720 uid=0
> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
> msg='op=PAM:setcred acct="tedx" exe="/usr/libexec/gdm-session-worker"
> (hostname=?, addr=?, terminal=:0 res=success)'
> type=USER_END msg=audit(1213049927.697:143): user pid=2720 uid=0
> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
> msg='op=PAM:session_close acct="tedx"
> exe="/usr/libexec/gdm-session-worker" (hostname=?, addr=?, terminal=:0
> res=success)'
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
>   


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: X in MLS enforcing problem

[Stephen Smalley]

On Mon, 2008-06-09 at 17:35 -0500, Xavier Toth wrote:
> On Mon, Jun 9, 2008 at 4:49 PM, Chad Hanson <chanson@trustedcs.com> wrote:
> >
> > mls_trusted_object(xdm_xserver_t) won't help this problem, but something
> > like mls_file_read_up and mls_file_write_down would be more approriate
> > for xdm_xserver_t.
> >
> > -Chad
> >
> >>
> >> type=AVC msg=audit(1213041678.053:8): avc:  denied  { read } for
> >> pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
> >> scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> >> tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
> >> tclass=chr_file
> >> type=AVC msg=audit(1213041678.432:10): avc:  denied  { write } for
> >> pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
> >> scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> >> tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
> >> tclass=chr_file
> >>
> >> The xserver_common_domain_template seems to have the necessary allow
> >> rules (dev_read_raw_memory and dev_wx_raw_memory) for the types so  I
> >> create a local module and added:
> >> mls_trusted_object(xdm_xserver_t)
> >> to deal with the MLS constraint violation but I'm still getting these
> >> AVC.What else can it be?
> >>
> >> Ted
> >>
> >
> 
> Indeed that would only work if the target (the chr_file) were an
> mls_trusted_object. So for now I'm using
> mls_file_(read/write)_all_levels and those AVCs are handled.
> 
> Now I looking at the USER_AVCs and trying to figure out how to
> translate those into policy. Will audit2allow be updated to help with
> generating rules for the X USER_AVCs?

It already handles them.

> For those who haven't seen the X user space object manager AVCs here
> are some examples:
> type=USER_AVC msg=audit(1213049927.142:132): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { blend } for request=X11:CreateWindow comm=dbus-launch resid=800001
> restype=WINDOW scontext=user_u:user_r:user_t:s0
> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
> type=USER_AVC msg=audit(1213049927.144:133): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { setattr } for request=X11:SetSelectionOwner comm=dbus-launch
> selection=_DBUS_SESSION_BUS_SELECTION_tedx_caa2282936b539cb3e36c2ae4845ed0b
> scontext=user_u:user_r:user_t:s0
> tcontext=system_u:object_r:xselection_t:s0 tclass=x_selection :
> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
> type=USER_AVC msg=audit(1213049927.227:134): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { manage } for request=X11:ChangeHosts comm=xhost
> scontext=user_u:user_r:user_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tclass=x_server : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
> terminal=?)'
> type=USER_AVC msg=audit(1213049927.653:135): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { blend } for request=X11:CreateWindow comm=gnome-session
> resid=800001 restype=WINDOW scontext=user_u:user_r:user_t:s0
> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
> type=USER_AVC msg=audit(1213049927.656:136): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { blend } for request=X11:CreateWindow comm=gnome-session
> resid=800002 restype=WINDOW scontext=user_u:user_r:user_t:s0
> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
> type=USER_AVC msg=audit(1213049927.659:137): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { getattr } for request=X11:QueryPointer comm=gnome-session
> xdevice="Virtual core pointer" scontext=user_u:user_r:user_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
> terminal=?)'
> type=USER_AVC msg=audit(1213049927.661:138): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
> terminal=?)'
> type=USER_AVC msg=audit(1213049927.661:139): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
> terminal=?)'
> type=USER_AVC msg=audit(1213049927.661:140): user pid=2636 uid=0
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>  { getattr setattr } for request=XKEYBOARD:PerClientFlags
> comm=gnome-session xdevice="Virtual core keyboard"
> scontext=user_u:user_r:user_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
> terminal=?)'
> type=ANOM_ABEND msg=audit(1213049927.662:141): auid=500 uid=500
> gid=500 ses=4 subj=user_u:user_r:user_t:s0 pid=3280
> comm="gnome-session" sig=5
> type=CRED_DISP msg=audit(1213049927.674:142): user pid=2720 uid=0
> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
> msg='op=PAM:setcred acct="tedx" exe="/usr/libexec/gdm-session-worker"
> (hostname=?, addr=?, terminal=:0 res=success)'
> type=USER_END msg=audit(1213049927.697:143): user pid=2720 uid=0
> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
> msg='op=PAM:session_close acct="tedx"
> exe="/usr/libexec/gdm-session-worker" (hostname=?, addr=?, terminal=:0
> res=success)'
> 
> --
> 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.
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: X in MLS enforcing problem

[Ted X Toth]

Eamon Walsh wrote:
> Xavier Toth wrote:
>
> [snip]
>
>> Now I looking at the USER_AVCs and trying to figure out how to
>> translate those into policy. Will audit2allow be updated to help with
>> generating rules for the X USER_AVCs?
>>   
>
> The stock audit2allow parses my audit.log just fine.  It doesn't work 
> for you?

It does I just made a mistake when copy/pasting AVCs while experimenting :(
>
>
>> For those who haven't seen the X user space object manager AVCs here
>> are some examples:
>> type=USER_AVC msg=audit(1213049927.142:132): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { blend } for request=X11:CreateWindow comm=dbus-launch resid=800001
>> restype=WINDOW scontext=user_u:user_r:user_t:s0
>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>   
>
> This is a program attempting to create a window with no background.  
> The denial will cause the window background to be filled in with a 
> solid color.
>
> Dontaudit should work here.
>
> However, window managers do need the blend permission (on all 
> windows).  The "compositing" feature requires this permission.
>
>
>> type=USER_AVC msg=audit(1213049927.144:133): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { setattr } for request=X11:SetSelectionOwner comm=dbus-launch
>> selection=_DBUS_SESSION_BUS_SELECTION_tedx_caa2282936b539cb3e36c2ae4845ed0b 
>>
>> scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:object_r:xselection_t:s0 tclass=x_selection :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>   
>
> This is a known issue.  I have not found an explanation yet for the 
> purpose of these D-BUS selections.
>
> There is no easy solution here.  The selabel system cannot handle 
> these funky names.  Even if there was regexp support, as Chris has 
> indicated the name contains a username, implying that it should be 
> labeled with a derived type.
>
> I think the "dbus-launch" program needs to undergo surgery to either 
> not create these things or to label them explicitly.
>
>

So what's the way forward here, open a bug against dbus? If the other 
AVCs are addressed would this still cause a session abend?

>> type=USER_AVC msg=audit(1213049927.227:134): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { manage } for request=X11:ChangeHosts comm=xhost
>> scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_server : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>>   
>
> Somewhere in the startup scripts xhost is being called to fiddle with 
> the lists of hosts that can connect to the server.
>
> Either solve the xdm_xserver_t versus user_xserver_t problem, which 
> has been much discussed, or grant the permission above, and rely on 
> the Xauthority mechanism to keep people from running xhost on other 
> people's servers.
>
> As to the former, I'm trying to get something working with setcon and 
> my GDM/pam_selinux patches.
>
>
>> type=USER_AVC msg=audit(1213049927.653:135): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { blend } for request=X11:CreateWindow comm=gnome-session
>> resid=800001 restype=WINDOW scontext=user_u:user_r:user_t:s0
>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>> type=USER_AVC msg=audit(1213049927.656:136): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { blend } for request=X11:CreateWindow comm=gnome-session
>> resid=800002 restype=WINDOW scontext=user_u:user_r:user_t:s0
>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>   
>
> More blend errors.
>
>
>> type=USER_AVC msg=audit(1213049927.659:137): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { getattr } for request=X11:QueryPointer comm=gnome-session
>> xdevice="Virtual core pointer" scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>>   
>
> The default label for devices is the server's context.  Another xdm / 
> user issue.
>
> My GDM/pam_selinux patches attempt to relabel the devices to the 
> user's context, the same way the terminal is relabeled when you log in 
> at the console.
>
>
>> type=USER_AVC msg=audit(1213049927.661:138): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
>> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>> type=USER_AVC msg=audit(1213049927.661:139): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
>> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>> type=USER_AVC msg=audit(1213049927.661:140): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { getattr setattr } for request=XKEYBOARD:PerClientFlags
>> comm=gnome-session xdevice="Virtual core keyboard"
>> scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>>   
>
> More device errors.
>
>> type=ANOM_ABEND msg=audit(1213049927.662:141): auid=500 uid=500
>> gid=500 ses=4 subj=user_u:user_r:user_t:s0 pid=3280
>> comm="gnome-session" sig=5
>>   
>
> Standard error handling behavior for the desktop.
>
>
>
>> type=CRED_DISP msg=audit(1213049927.674:142): user pid=2720 uid=0
>> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
>> msg='op=PAM:setcred acct="tedx" exe="/usr/libexec/gdm-session-worker"
>> (hostname=?, addr=?, terminal=:0 res=success)'
>> type=USER_END msg=audit(1213049927.697:143): user pid=2720 uid=0
>> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
>> msg='op=PAM:session_close acct="tedx"
>> exe="/usr/libexec/gdm-session-worker" (hostname=?, addr=?, terminal=:0
>> res=success)'
>>
>> -- 
>> 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 message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: X in MLS enforcing problem

[Ted X Toth]

Eamon Walsh wrote:
> Xavier Toth wrote:
>
> [snip]
>
>> Now I looking at the USER_AVCs and trying to figure out how to
>> translate those into policy. Will audit2allow be updated to help with
>> generating rules for the X USER_AVCs?
>>   
>
> The stock audit2allow parses my audit.log just fine.  It doesn't work 
> for you?
>
>
>> For those who haven't seen the X user space object manager AVCs here
>> are some examples:
>> type=USER_AVC msg=audit(1213049927.142:132): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { blend } for request=X11:CreateWindow comm=dbus-launch resid=800001
>> restype=WINDOW scontext=user_u:user_r:user_t:s0
>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>   
>
> This is a program attempting to create a window with no background.  
> The denial will cause the window background to be filled in with a 
> solid color.
>
> Dontaudit should work here.
>
> However, window managers do need the blend permission (on all 
> windows).  The "compositing" feature requires this permission.
>
>
>> type=USER_AVC msg=audit(1213049927.144:133): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { setattr } for request=X11:SetSelectionOwner comm=dbus-launch
>> selection=_DBUS_SESSION_BUS_SELECTION_tedx_caa2282936b539cb3e36c2ae4845ed0b 
>>
>> scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:object_r:xselection_t:s0 tclass=x_selection :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>   
>
> This is a known issue.  I have not found an explanation yet for the 
> purpose of these D-BUS selections.
>
> There is no easy solution here.  The selabel system cannot handle 
> these funky names.  Even if there was regexp support, as Chris has 
> indicated the name contains a username, implying that it should be 
> labeled with a derived type.
>
> I think the "dbus-launch" program needs to undergo surgery to either 
> not create these things or to label them explicitly.
>

I looked at dbus-launch briefly and it appears that the window which is 
never mapped is used as storage for a couple of properties, the dbus 
address and pid. The selection is used to indicate if another 
dbus-launch is active and if it is its' address and pid are returned and 
the current dbus-launch exits. I guess there is only supposed to be one 
dbus for a given user on a given machine.
>
>> type=USER_AVC msg=audit(1213049927.227:134): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { manage } for request=X11:ChangeHosts comm=xhost
>> scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_server : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>>   
>
> Somewhere in the startup scripts xhost is being called to fiddle with 
> the lists of hosts that can connect to the server.
>
> Either solve the xdm_xserver_t versus user_xserver_t problem, which 
> has been much discussed, or grant the permission above, and rely on 
> the Xauthority mechanism to keep people from running xhost on other 
> people's servers.
>
> As to the former, I'm trying to get something working with setcon and 
> my GDM/pam_selinux patches.
>
>
>> type=USER_AVC msg=audit(1213049927.653:135): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { blend } for request=X11:CreateWindow comm=gnome-session
>> resid=800001 restype=WINDOW scontext=user_u:user_r:user_t:s0
>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>> type=USER_AVC msg=audit(1213049927.656:136): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { blend } for request=X11:CreateWindow comm=gnome-session
>> resid=800002 restype=WINDOW scontext=user_u:user_r:user_t:s0
>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>   
>
> More blend errors.
>
>
>> type=USER_AVC msg=audit(1213049927.659:137): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { getattr } for request=X11:QueryPointer comm=gnome-session
>> xdevice="Virtual core pointer" scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>>   
>
> The default label for devices is the server's context.  Another xdm / 
> user issue.
>
> My GDM/pam_selinux patches attempt to relabel the devices to the 
> user's context, the same way the terminal is relabeled when you log in 
> at the console.
>
>
>> type=USER_AVC msg=audit(1213049927.661:138): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
>> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>> type=USER_AVC msg=audit(1213049927.661:139): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
>> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>> type=USER_AVC msg=audit(1213049927.661:140): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { getattr setattr } for request=XKEYBOARD:PerClientFlags
>> comm=gnome-session xdevice="Virtual core keyboard"
>> scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>>   
>
> More device errors.
>
>> type=ANOM_ABEND msg=audit(1213049927.662:141): auid=500 uid=500
>> gid=500 ses=4 subj=user_u:user_r:user_t:s0 pid=3280
>> comm="gnome-session" sig=5
>>   
>
> Standard error handling behavior for the desktop.
>
>
>
>> type=CRED_DISP msg=audit(1213049927.674:142): user pid=2720 uid=0
>> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
>> msg='op=PAM:setcred acct="tedx" exe="/usr/libexec/gdm-session-worker"
>> (hostname=?, addr=?, terminal=:0 res=success)'
>> type=USER_END msg=audit(1213049927.697:143): user pid=2720 uid=0
>> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
>> msg='op=PAM:session_close acct="tedx"
>> exe="/usr/libexec/gdm-session-worker" (hostname=?, addr=?, terminal=:0
>> res=success)'
>>
>> -- 
>> 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 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.

MLS constraint interfaces

[Ted X Toth]

Chad Hanson wrote:
> mls_trusted_object(xdm_xserver_t) won't help this problem, but something
> like mls_file_read_up and mls_file_write_down would be more approriate
> for xdm_xserver_t.
>
> -Chad
>
>   
>> type=AVC msg=audit(1213041678.053:8): avc:  denied  { read } for
>> pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
>> scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
>> tclass=chr_file
>> type=AVC msg=audit(1213041678.432:10): avc:  denied  { write } for
>> pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
>> scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
>> tclass=chr_file
>>
>> The xserver_common_domain_template seems to have the necessary allow
>> rules (dev_read_raw_memory and dev_wx_raw_memory) for the types so  I
>> create a local module and added:
>> mls_trusted_object(xdm_xserver_t)
>> to deal with the MLS constraint violation but I'm still getting these
>> AVC.What else can it be?
>>
>> Ted
>>
>>     
>
>   
As I said in another post I've added mls interface calls to deal with 
these constraint violations. However I'm concerned about the breath of 
the interfaces in that they cover many classes/types of files when as 
far as I know the X server really only needs multilevel access to 
'chr_file'. Should there be more class specific interfaces?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: X in MLS enforcing problem

[Ted X Toth]

Eamon Walsh wrote:
> Xavier Toth wrote:
>
> [snip]
>
>> Now I looking at the USER_AVCs and trying to figure out how to
>> translate those into policy. Will audit2allow be updated to help with
>> generating rules for the X USER_AVCs?
>>   
>
> The stock audit2allow parses my audit.log just fine.  It doesn't work 
> for you?
>
>
>> For those who haven't seen the X user space object manager AVCs here
>> are some examples:
>> type=USER_AVC msg=audit(1213049927.142:132): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { blend } for request=X11:CreateWindow comm=dbus-launch resid=800001
>> restype=WINDOW scontext=user_u:user_r:user_t:s0
>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>   
>
> This is a program attempting to create a window with no background.  
> The denial will cause the window background to be filled in with a 
> solid color.
>
> Dontaudit should work here.
>
> However, window managers do need the blend permission (on all 
> windows).  The "compositing" feature requires this permission.
>
>
>> type=USER_AVC msg=audit(1213049927.144:133): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { setattr } for request=X11:SetSelectionOwner comm=dbus-launch
>> selection=_DBUS_SESSION_BUS_SELECTION_tedx_caa2282936b539cb3e36c2ae4845ed0b 
>>
>> scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:object_r:xselection_t:s0 tclass=x_selection :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>   
>
> This is a known issue.  I have not found an explanation yet for the 
> purpose of these D-BUS selections.
>
> There is no easy solution here.  The selabel system cannot handle 
> these funky names.  Even if there was regexp support, as Chris has 
> indicated the name contains a username, implying that it should be 
> labeled with a derived type.
>
> I think the "dbus-launch" program needs to undergo surgery to either 
> not create these things or to label them explicitly.
If I were to do this I'd use either SetSelectionCreateContext or 
SetSelectionUseContext, could you explain the difference between them 
and which I should use?
>
>
>> type=USER_AVC msg=audit(1213049927.227:134): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { manage } for request=X11:ChangeHosts comm=xhost
>> scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_server : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>>   
>
> Somewhere in the startup scripts xhost is being called to fiddle with 
> the lists of hosts that can connect to the server.
>
> Either solve the xdm_xserver_t versus user_xserver_t problem, which 
> has been much discussed, or grant the permission above, and rely on 
> the Xauthority mechanism to keep people from running xhost on other 
> people's servers.
>
> As to the former, I'm trying to get something working with setcon and 
> my GDM/pam_selinux patches.
>
>
>> type=USER_AVC msg=audit(1213049927.653:135): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { blend } for request=X11:CreateWindow comm=gnome-session
>> resid=800001 restype=WINDOW scontext=user_u:user_r:user_t:s0
>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>> type=USER_AVC msg=audit(1213049927.656:136): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { blend } for request=X11:CreateWindow comm=gnome-session
>> resid=800002 restype=WINDOW scontext=user_u:user_r:user_t:s0
>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>   
>
> More blend errors.
>
>
>> type=USER_AVC msg=audit(1213049927.659:137): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { getattr } for request=X11:QueryPointer comm=gnome-session
>> xdevice="Virtual core pointer" scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>>   
>
> The default label for devices is the server's context.  Another xdm / 
> user issue.
>
> My GDM/pam_selinux patches attempt to relabel the devices to the 
> user's context, the same way the terminal is relabeled when you log in 
> at the console.
>
>
>> type=USER_AVC msg=audit(1213049927.661:138): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
>> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>> type=USER_AVC msg=audit(1213049927.661:139): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
>> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>> type=USER_AVC msg=audit(1213049927.661:140): user pid=2636 uid=0
>> auid=4294967295 ses=4294967295
>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>  { getattr setattr } for request=XKEYBOARD:PerClientFlags
>> comm=gnome-session xdevice="Virtual core keyboard"
>> scontext=user_u:user_r:user_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>> terminal=?)'
>>   
>
> More device errors.
>
>> type=ANOM_ABEND msg=audit(1213049927.662:141): auid=500 uid=500
>> gid=500 ses=4 subj=user_u:user_r:user_t:s0 pid=3280
>> comm="gnome-session" sig=5
>>   
>
> Standard error handling behavior for the desktop.
>
>
>
>> type=CRED_DISP msg=audit(1213049927.674:142): user pid=2720 uid=0
>> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
>> msg='op=PAM:setcred acct="tedx" exe="/usr/libexec/gdm-session-worker"
>> (hostname=?, addr=?, terminal=:0 res=success)'
>> type=USER_END msg=audit(1213049927.697:143): user pid=2720 uid=0
>> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
>> msg='op=PAM:session_close acct="tedx"
>> exe="/usr/libexec/gdm-session-worker" (hostname=?, addr=?, terminal=:0
>> res=success)'
>>
>> -- 
>> 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 message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: MLS constraint interfaces

[Chad Hanson]

Our initial MLS design and implementation kept things at the same level
of granularity as previous MLS implementations. SELinux is far more
granular and could support class specific MLS "privileges". TE policy
can help prevent unintended use of the "privilege" since a policy may
not permit write access to etc_t:s0, even though you have MLS write
access running at s1 (from the mlsfilewrite attribute).

If we wanted to be more granular in the class specifications, we would
need to create the specific interfaces and adjust the MLS constraint
file accordingly. If you have patch, we can review it. (I'm going to be
unavailable for a little over a week starting on Friday).

-Chad

> As I said in another post I've added mls interface calls to deal with 
> these constraint violations. However I'm concerned about the 
> breath of 
> the interfaces in that they cover many classes/types of files when as 
> far as I know the X server really only needs multilevel access to 
> 'chr_file'. Should there be more class specific interfaces?
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: X in MLS enforcing problem

[Xavier Toth]

On Wed, Jun 11, 2008 at 8:48 AM, Ted X Toth <txtoth@gmail.com> wrote:
> Eamon Walsh wrote:
>>
>> Xavier Toth wrote:
>>
>> [snip]
>>
>>> Now I looking at the USER_AVCs and trying to figure out how to
>>> translate those into policy. Will audit2allow be updated to help with
>>> generating rules for the X USER_AVCs?
>>>
>>
>> The stock audit2allow parses my audit.log just fine.  It doesn't work for
>> you?
>>
>>
>>> For those who haven't seen the X user space object manager AVCs here
>>> are some examples:
>>> type=USER_AVC msg=audit(1213049927.142:132): user pid=2636 uid=0
>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>  { blend } for request=X11:CreateWindow comm=dbus-launch resid=800001
>>> restype=WINDOW scontext=user_u:user_r:user_t:s0
>>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>>
>>
>> This is a program attempting to create a window with no background.  The
>> denial will cause the window background to be filled in with a solid color.
>>
>> Dontaudit should work here.
>>
>> However, window managers do need the blend permission (on all windows).
>>  The "compositing" feature requires this permission.
>>
>>
>>> type=USER_AVC msg=audit(1213049927.144:133): user pid=2636 uid=0
>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>  { setattr } for request=X11:SetSelectionOwner comm=dbus-launch
>>>
>>> selection=_DBUS_SESSION_BUS_SELECTION_tedx_caa2282936b539cb3e36c2ae4845ed0b
>>> scontext=user_u:user_r:user_t:s0
>>> tcontext=system_u:object_r:xselection_t:s0 tclass=x_selection :
>>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>>
>>
>> This is a known issue.  I have not found an explanation yet for the
>> purpose of these D-BUS selections.
>>
>> There is no easy solution here.  The selabel system cannot handle these
>> funky names.  Even if there was regexp support, as Chris has indicated the
>> name contains a username, implying that it should be labeled with a derived
>> type.
>>
>> I think the "dbus-launch" program needs to undergo surgery to either not
>> create these things or to label them explicitly.
>
> If I were to do this I'd use either SetSelectionCreateContext or
> SetSelectionUseContext, could you explain the difference between them and
> which I should use?

I also will need to compute a new context from the process and default
selection contexts but I'd need an object class definition
(SECCLASS_XSELECTION?) which I don't think exists yet does it?

>>
>>
>>> type=USER_AVC msg=audit(1213049927.227:134): user pid=2636 uid=0
>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>  { manage } for request=X11:ChangeHosts comm=xhost
>>> scontext=user_u:user_r:user_t:s0
>>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>>> tclass=x_server : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>>> terminal=?)'
>>>
>>
>> Somewhere in the startup scripts xhost is being called to fiddle with the
>> lists of hosts that can connect to the server.
>>
>> Either solve the xdm_xserver_t versus user_xserver_t problem, which has
>> been much discussed, or grant the permission above, and rely on the
>> Xauthority mechanism to keep people from running xhost on other people's
>> servers.
>>
>> As to the former, I'm trying to get something working with setcon and my
>> GDM/pam_selinux patches.
>>
>>
>>> type=USER_AVC msg=audit(1213049927.653:135): user pid=2636 uid=0
>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>  { blend } for request=X11:CreateWindow comm=gnome-session
>>> resid=800001 restype=WINDOW scontext=user_u:user_r:user_t:s0
>>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>> type=USER_AVC msg=audit(1213049927.656:136): user pid=2636 uid=0
>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>  { blend } for request=X11:CreateWindow comm=gnome-session
>>> resid=800002 restype=WINDOW scontext=user_u:user_r:user_t:s0
>>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>>
>>
>> More blend errors.
>>
>>
>>> type=USER_AVC msg=audit(1213049927.659:137): user pid=2636 uid=0
>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>  { getattr } for request=X11:QueryPointer comm=gnome-session
>>> xdevice="Virtual core pointer" scontext=user_u:user_r:user_t:s0
>>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>>> terminal=?)'
>>>
>>
>> The default label for devices is the server's context.  Another xdm / user
>> issue.
>>
>> My GDM/pam_selinux patches attempt to relabel the devices to the user's
>> context, the same way the terminal is relabeled when you log in at the
>> console.
>>
>>
>>> type=USER_AVC msg=audit(1213049927.661:138): user pid=2636 uid=0
>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
>>> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
>>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>>> terminal=?)'
>>> type=USER_AVC msg=audit(1213049927.661:139): user pid=2636 uid=0
>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>  { use } for request=XKEYBOARD:SelectEvents comm=gnome-session
>>> xdevice="Virtual core keyboard" scontext=user_u:user_r:user_t:s0
>>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>>> terminal=?)'
>>> type=USER_AVC msg=audit(1213049927.661:140): user pid=2636 uid=0
>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>  { getattr setattr } for request=XKEYBOARD:PerClientFlags
>>> comm=gnome-session xdevice="Virtual core keyboard"
>>> scontext=user_u:user_r:user_t:s0
>>> tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>>> tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?,
>>> terminal=?)'
>>>
>>
>> More device errors.
>>
>>> type=ANOM_ABEND msg=audit(1213049927.662:141): auid=500 uid=500
>>> gid=500 ses=4 subj=user_u:user_r:user_t:s0 pid=3280
>>> comm="gnome-session" sig=5
>>>
>>
>> Standard error handling behavior for the desktop.
>>
>>
>>
>>> type=CRED_DISP msg=audit(1213049927.674:142): user pid=2720 uid=0
>>> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
>>> msg='op=PAM:setcred acct="tedx" exe="/usr/libexec/gdm-session-worker"
>>> (hostname=?, addr=?, terminal=:0 res=success)'
>>> type=USER_END msg=audit(1213049927.697:143): user pid=2720 uid=0
>>> auid=500 ses=4 subj=system_u:system_r:xdm_t:s0-s15:c0.c1023
>>> msg='op=PAM:session_close acct="tedx"
>>> exe="/usr/libexec/gdm-session-worker" (hostname=?, addr=?, terminal=:0
>>> res=success)'
>>>
>>> --
>>> 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 message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: X in MLS enforcing problem

[Eamon Walsh]

Ted X Toth wrote:
> If I were to do this I'd use either SetSelectionCreateContext or 
> SetSelectionUseContext, could you explain the difference between them 
> and which I should use?
>   
>

SetSelectionCreateContext is for setting the context on the clipboard 
_data_.  This is how an SELinux-aware application could specify what 
type of data the user has made available for pasting.  The 
"x_application_data" security class represents the "object" labeled by 
this context, and the selection manager is responsible for checking 
permission on it.  The X server doesn't perform any checks on this 
context.  See earlier message [1].

SetSelectionUseContext is for setting the context of the selection 
object itself.  It was intended to be used by a selection manager that 
supports polyinstantiation.  It sets the context of the selection object 
that the client wants to "use".  So for example if there are three 
PRIMARY selections labeled foo_t, bar_t, and baz_t the selection manager 
can choose the one to operate on using SetSelectionUseContext.

In the non-polyinstantiated case, SetSelectionUseContext can be used to 
override the value from x_contexts and set the label on the one object 
that will be seen by everyone (which is what we want to do with 
dbus_launch).  This only works if the selection doesn't already exist 
because there's currently no way to change the label on an existing object.

So in summary:

Clipboard data - x_application_data object class
SetSelectionCreateContext / GetSelectionDataContext
checked by selection manager

Clipboard object - x_selection object class
SetSelectionUseContext / GetSelectionContext
checked by X server


One more note: the clipboard data context currently defaults to the 
selection's context (e.g. clipboard_xselection_t), but I think it might 
be more logical to default it to the client program's context (user_t).  
This would require a change to the X server.

[1] http://marc.info/?l=selinux&m=120701081703490&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.

Re: X in MLS enforcing problem

[Eamon Walsh]

Xavier Toth wrote:
> On Wed, Jun 11, 2008 at 8:48 AM, Ted X Toth <txtoth@gmail.com> wrote:
>   
>> Eamon Walsh wrote:
>>     
>>> Xavier Toth wrote:
>>>
>>> [snip]
>>>
>>>       
>>>> Now I looking at the USER_AVCs and trying to figure out how to
>>>> translate those into policy. Will audit2allow be updated to help with
>>>> generating rules for the X USER_AVCs?
>>>>
>>>>         
>>> The stock audit2allow parses my audit.log just fine.  It doesn't work for
>>> you?
>>>
>>>
>>>       
>>>> For those who haven't seen the X user space object manager AVCs here
>>>> are some examples:
>>>> type=USER_AVC msg=audit(1213049927.142:132): user pid=2636 uid=0
>>>> auid=4294967295 ses=4294967295
>>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>>  { blend } for request=X11:CreateWindow comm=dbus-launch resid=800001
>>>> restype=WINDOW scontext=user_u:user_r:user_t:s0
>>>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>>>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>>>
>>>>         
>>> This is a program attempting to create a window with no background.  The
>>> denial will cause the window background to be filled in with a solid color.
>>>
>>> Dontaudit should work here.
>>>
>>> However, window managers do need the blend permission (on all windows).
>>>  The "compositing" feature requires this permission.
>>>
>>>
>>>       
>>>> type=USER_AVC msg=audit(1213049927.144:133): user pid=2636 uid=0
>>>> auid=4294967295 ses=4294967295
>>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>>  { setattr } for request=X11:SetSelectionOwner comm=dbus-launch
>>>>
>>>> selection=_DBUS_SESSION_BUS_SELECTION_tedx_caa2282936b539cb3e36c2ae4845ed0b
>>>> scontext=user_u:user_r:user_t:s0
>>>> tcontext=system_u:object_r:xselection_t:s0 tclass=x_selection :
>>>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>>>
>>>>         
>>> This is a known issue.  I have not found an explanation yet for the
>>> purpose of these D-BUS selections.
>>>
>>> There is no easy solution here.  The selabel system cannot handle these
>>> funky names.  Even if there was regexp support, as Chris has indicated the
>>> name contains a username, implying that it should be labeled with a derived
>>> type.
>>>
>>> I think the "dbus-launch" program needs to undergo surgery to either not
>>> create these things or to label them explicitly.
>>>       
>> If I were to do this I'd use either SetSelectionCreateContext or
>> SetSelectionUseContext, could you explain the difference between them and
>> which I should use?
>>     
>
> I also will need to compute a new context from the process and default
> selection contexts but I'd need an object class definition
> (SECCLASS_XSELECTION?) which I don't think exists yet does it?
>   


Use class x_selection.  To find it's value dynamically, you can use the 
following code.

#define THE_CLASS 1

    security_class_mapping map[] = { { "x_drawable", { NULL } }, { NULL } };

    if (selinux_set_mapping(map) < 0)
	/* probably don't have class - skip SELinux stuff */


Then use THE_CLASS (or just "1") as the class value in your code.

Lots of questions about these interfaces lately - I need to write man 
pages for them.



-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: X in MLS enforcing problem

[Eamon Walsh]

Eamon Walsh wrote:

[snip]
>     security_class_mapping map[] = { { "x_drawable", { NULL } }, { NULL } };
>   

I meant "x_selection" above.


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: X in MLS enforcing problem

[Xavier Toth]

On Wed, Jun 11, 2008 at 4:59 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Xavier Toth wrote:
>>
>> On Wed, Jun 11, 2008 at 8:48 AM, Ted X Toth <txtoth@gmail.com> wrote:
>>
>>>
>>> Eamon Walsh wrote:
>>>
>>>>
>>>> Xavier Toth wrote:
>>>>
>>>> [snip]
>>>>
>>>>
>>>>>
>>>>> Now I looking at the USER_AVCs and trying to figure out how to
>>>>> translate those into policy. Will audit2allow be updated to help with
>>>>> generating rules for the X USER_AVCs?
>>>>>
>>>>>
>>>>
>>>> The stock audit2allow parses my audit.log just fine.  It doesn't work
>>>> for
>>>> you?
>>>>
>>>>
>>>>
>>>>>
>>>>> For those who haven't seen the X user space object manager AVCs here
>>>>> are some examples:
>>>>> type=USER_AVC msg=audit(1213049927.142:132): user pid=2636 uid=0
>>>>> auid=4294967295 ses=4294967295
>>>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>>>  { blend } for request=X11:CreateWindow comm=dbus-launch resid=800001
>>>>> restype=WINDOW scontext=user_u:user_r:user_t:s0
>>>>> tcontext=user_u:object_r:user_t:s0 tclass=x_drawable :
>>>>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>>>>
>>>>>
>>>>
>>>> This is a program attempting to create a window with no background.  The
>>>> denial will cause the window background to be filled in with a solid
>>>> color.
>>>>
>>>> Dontaudit should work here.
>>>>
>>>> However, window managers do need the blend permission (on all windows).
>>>>  The "compositing" feature requires this permission.
>>>>
>>>>
>>>>
>>>>>
>>>>> type=USER_AVC msg=audit(1213049927.144:133): user pid=2636 uid=0
>>>>> auid=4294967295 ses=4294967295
>>>>> subj=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 msg='avc:  denied
>>>>>  { setattr } for request=X11:SetSelectionOwner comm=dbus-launch
>>>>>
>>>>>
>>>>> selection=_DBUS_SESSION_BUS_SELECTION_tedx_caa2282936b539cb3e36c2ae4845ed0b
>>>>> scontext=user_u:user_r:user_t:s0
>>>>> tcontext=system_u:object_r:xselection_t:s0 tclass=x_selection :
>>>>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>>>>
>>>>>
>>>>
>>>> This is a known issue.  I have not found an explanation yet for the
>>>> purpose of these D-BUS selections.
>>>>
>>>> There is no easy solution here.  The selabel system cannot handle these
>>>> funky names.  Even if there was regexp support, as Chris has indicated
>>>> the
>>>> name contains a username, implying that it should be labeled with a
>>>> derived
>>>> type.
>>>>
>>>> I think the "dbus-launch" program needs to undergo surgery to either not
>>>> create these things or to label them explicitly.
>>>>
>>>
>>> If I were to do this I'd use either SetSelectionCreateContext or
>>> SetSelectionUseContext, could you explain the difference between them and
>>> which I should use?
>>>
>>
>> I also will need to compute a new context from the process and default
>> selection contexts but I'd need an object class definition
>> (SECCLASS_XSELECTION?) which I don't think exists yet does it?
>>
>
>
> Use class x_selection.  To find it's value dynamically, you can use the
> following code.
>
> #define THE_CLASS 1
>
>   security_class_mapping map[] = { { "x_drawable", { NULL } }, { NULL } };
>
>   if (selinux_set_mapping(map) < 0)
>        /* probably don't have class - skip SELinux stuff */
>
>
> Then use THE_CLASS (or just "1") as the class value in your code.
>
> Lots of questions about these interfaces lately - I need to write man pages
> for them.

Agreed.

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