Permissive mode for xace is broken.

Permissive mode for xace is broken.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I turn on xserver_object_manager in rawhide and log in as staff_t in
permissive mode, I get all sorts of things failing, which makes writing
policy for it very difficult.  And is very broken.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfCzBgACgkQrlYvE4MpobNniwCgnj1slFGDRupI/ljcDwC5b/Hc
lDIAnREcNwgXgfwBRwWtUY1VZt902IZ+
=WuKh
-----END PGP SIGNATURE-----

--
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: Permissive mode for xace is broken.

[Stephen Smalley]

On Mon, 2008-02-25 at 09:09 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> If I turn on xserver_object_manager in rawhide and log in as staff_t in
> permissive mode, I get all sorts of things failing, which makes writing
> policy for it very difficult.  And is very broken.

Hmmm...as I understood it, XSELinux should follow the kernel's enforcing
status by default (i.e. if the kernel is permissive, then so should
XSELinux), unless you explicitly configure enforcing= in xorg.conf to
specify a different setting for the X server than the kernel.  You are
supposed to be able to make the X server permissive w/o making the
kernel permissive via xorg configuration, I believe, although I'm not
sure that made it into the rawhide xorg yet.

-- 
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: Permissive mode for xace is broken.

[Stephen Smalley]

On Mon, 2008-02-25 at 09:12 -0500, Stephen Smalley wrote:
> On Mon, 2008-02-25 at 09:09 -0500, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > If I turn on xserver_object_manager in rawhide and log in as staff_t in
> > permissive mode, I get all sorts of things failing, which makes writing
> > policy for it very difficult.  And is very broken.
> 
> Hmmm...as I understood it, XSELinux should follow the kernel's enforcing
> status by default (i.e. if the kernel is permissive, then so should
> XSELinux), unless you explicitly configure enforcing= in xorg.conf to
> specify a different setting for the X server than the kernel.  You are
> supposed to be able to make the X server permissive w/o making the
> kernel permissive via xorg configuration, I believe, although I'm not
> sure that made it into the rawhide xorg yet.

Doesn't look like the rawhide xorg server has that support yet.

But it should follow the kernel's enforcing status.  You should see log
messages with "received setenforce notice (enforcing=...)" in them from
both dbus and X in either /var/log/messages or /var/log/audit/audit.log.

-- 
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: Permissive mode for xace is broken.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Mon, 2008-02-25 at 09:12 -0500, Stephen Smalley wrote:
>> On Mon, 2008-02-25 at 09:09 -0500, Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> If I turn on xserver_object_manager in rawhide and log in as staff_t in
>>> permissive mode, I get all sorts of things failing, which makes writing
>>> policy for it very difficult.  And is very broken.
>> Hmmm...as I understood it, XSELinux should follow the kernel's enforcing
>> status by default (i.e. if the kernel is permissive, then so should
>> XSELinux), unless you explicitly configure enforcing= in xorg.conf to
>> specify a different setting for the X server than the kernel.  You are
>> supposed to be able to make the X server permissive w/o making the
>> kernel permissive via xorg configuration, I believe, although I'm not
>> sure that made it into the rawhide xorg yet.
> 
> Doesn't look like the rawhide xorg server has that support yet.
> 
> But it should follow the kernel's enforcing status.  You should see log
> messages with "received setenforce notice (enforcing=...)" in them from
> both dbus and X in either /var/log/messages or /var/log/audit/audit.log.
> 
Looking at the code, I do not see security_getenforce() in the code.
Are you saying that this is not necessary, the kernel will return
allowed but generate the AVC?

And the only one who mentions setenforce in /var/log/audit/audit.log in
dbus not X?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfC1VIACgkQrlYvE4MpobMGbgCgsApumkxRzzo21JtgjE8S1psc
GpQAoNt6178sE4a0tWpICiErtJw1MzqH
=ZTuN
-----END PGP SIGNATURE-----

--
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: Permissive mode for xace is broken.

[Stephen Smalley]

On Mon, 2008-02-25 at 09:48 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Mon, 2008-02-25 at 09:12 -0500, Stephen Smalley wrote:
> >> On Mon, 2008-02-25 at 09:09 -0500, Daniel J Walsh wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> If I turn on xserver_object_manager in rawhide and log in as staff_t in
> >>> permissive mode, I get all sorts of things failing, which makes writing
> >>> policy for it very difficult.  And is very broken.
> >> Hmmm...as I understood it, XSELinux should follow the kernel's enforcing
> >> status by default (i.e. if the kernel is permissive, then so should
> >> XSELinux), unless you explicitly configure enforcing= in xorg.conf to
> >> specify a different setting for the X server than the kernel.  You are
> >> supposed to be able to make the X server permissive w/o making the
> >> kernel permissive via xorg configuration, I believe, although I'm not
> >> sure that made it into the rawhide xorg yet.
> > 
> > Doesn't look like the rawhide xorg server has that support yet.
> > 
> > But it should follow the kernel's enforcing status.  You should see log
> > messages with "received setenforce notice (enforcing=...)" in them from
> > both dbus and X in either /var/log/messages or /var/log/audit/audit.log.
> > 
> Looking at the code, I do not see security_getenforce() in the code.
> Are you saying that this is not necessary, the kernel will return
> allowed but generate the AVC?

Handling of enforcing status is hidden within the userspace AVC in
libselinux (libselinux/src/avc*.c).  avc_enforcing stores the current
value of the enforcing status and is updated when the kernel generates
the setenforce notification.  avc_setenforce is set if the object
manager explicitly sets its own enforcing mode to a specific value to
override the kernel status.

> And the only one who mentions setenforce in /var/log/audit/audit.log in
> dbus not X?

Hmmm...that's seems like a bug in X then, that it isn't getting the
notifications from the kernel (via netlink).

-- 
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: Permissive mode for xace is broken.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Mon, 2008-02-25 at 09:48 -0500, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Stephen Smalley wrote:
>>> On Mon, 2008-02-25 at 09:12 -0500, Stephen Smalley wrote:
>>>> On Mon, 2008-02-25 at 09:09 -0500, Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> If I turn on xserver_object_manager in rawhide and log in as staff_t in
>>>>> permissive mode, I get all sorts of things failing, which makes writing
>>>>> policy for it very difficult.  And is very broken.
>>>> Hmmm...as I understood it, XSELinux should follow the kernel's enforcing
>>>> status by default (i.e. if the kernel is permissive, then so should
>>>> XSELinux), unless you explicitly configure enforcing= in xorg.conf to
>>>> specify a different setting for the X server than the kernel.  You are
>>>> supposed to be able to make the X server permissive w/o making the
>>>> kernel permissive via xorg configuration, I believe, although I'm not
>>>> sure that made it into the rawhide xorg yet.
>>> Doesn't look like the rawhide xorg server has that support yet.
>>>
>>> But it should follow the kernel's enforcing status.  You should see log
>>> messages with "received setenforce notice (enforcing=...)" in them from
>>> both dbus and X in either /var/log/messages or /var/log/audit/audit.log.
>>>
>> Looking at the code, I do not see security_getenforce() in the code.
>> Are you saying that this is not necessary, the kernel will return
>> allowed but generate the AVC?
> 
> Handling of enforcing status is hidden within the userspace AVC in
> libselinux (libselinux/src/avc*.c).  avc_enforcing stores the current
> value of the enforcing status and is updated when the kernel generates
> the setenforce notification.  avc_setenforce is set if the object
> manager explicitly sets its own enforcing mode to a specific value to
> override the kernel status.
> 
>> And the only one who mentions setenforce in /var/log/audit/audit.log in
>> dbus not X?
> 
> Hmmm...that's seems like a bug in X then, that it isn't getting the
> notifications from the kernel (via netlink).
> 
Yes XAce seems to be very broken in Rawhide.  Enforcing mode was working
until I fixed the policy to allow xserver to talk to /selinux and run
the validation routines.  Now xace is blowing up both in permissive and
enforcing mode.

Trying to start nm-applet is getting a BadWindow error.

If you update to todays rawhide and try to login in permissive mode,
metacity and gconf will blow up.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfDFu4ACgkQrlYvE4MpobM2dQCfXP1SkniRYwFpx/tBKMJyNLK7
WkEAmwcUaOmOJtYZwbmRTrqOgrRb8r6l
=N2VI
-----END PGP SIGNATURE-----

--
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: Permissive mode for xace is broken.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel J Walsh wrote:
> Stephen Smalley wrote:
>> On Mon, 2008-02-25 at 09:48 -0500, Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Stephen Smalley wrote:
>>>> On Mon, 2008-02-25 at 09:12 -0500, Stephen Smalley wrote:
>>>>> On Mon, 2008-02-25 at 09:09 -0500, Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> If I turn on xserver_object_manager in rawhide and log in as staff_t in
>>>>>> permissive mode, I get all sorts of things failing, which makes writing
>>>>>> policy for it very difficult.  And is very broken.
>>>>> Hmmm...as I understood it, XSELinux should follow the kernel's enforcing
>>>>> status by default (i.e. if the kernel is permissive, then so should
>>>>> XSELinux), unless you explicitly configure enforcing= in xorg.conf to
>>>>> specify a different setting for the X server than the kernel.  You are
>>>>> supposed to be able to make the X server permissive w/o making the
>>>>> kernel permissive via xorg configuration, I believe, although I'm not
>>>>> sure that made it into the rawhide xorg yet.
>>>> Doesn't look like the rawhide xorg server has that support yet.
>>>>
>>>> But it should follow the kernel's enforcing status.  You should see log
>>>> messages with "received setenforce notice (enforcing=...)" in them from
>>>> both dbus and X in either /var/log/messages or /var/log/audit/audit.log.
>>>>
>>> Looking at the code, I do not see security_getenforce() in the code.
>>> Are you saying that this is not necessary, the kernel will return
>>> allowed but generate the AVC?
>> Handling of enforcing status is hidden within the userspace AVC in
>> libselinux (libselinux/src/avc*.c).  avc_enforcing stores the current
>> value of the enforcing status and is updated when the kernel generates
>> the setenforce notification.  avc_setenforce is set if the object
>> manager explicitly sets its own enforcing mode to a specific value to
>> override the kernel status.
> 
>>> And the only one who mentions setenforce in /var/log/audit/audit.log in
>>> dbus not X?
>> Hmmm...that's seems like a bug in X then, that it isn't getting the
>> notifications from the kernel (via netlink).
> 
> Yes XAce seems to be very broken in Rawhide.  Enforcing mode was working
> until I fixed the policy to allow xserver to talk to /selinux and run
> the validation routines.  Now xace is blowing up both in permissive and
> enforcing mode.
> 
> Trying to start nm-applet is getting a BadWindow error.
> 
> If you update to todays rawhide and try to login in permissive mode,
> metacity and gconf will blow up.
> 

nm-applet --sync
The program 'nm-applet' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 228 error_code 3 request_code 2 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


This is a serious problem, and needs to be fixed ASAP, or I need to pull
support for xace from policy.

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfDISsACgkQrlYvE4MpobMlYQCggrKUB4HabHGsMwLfG5+nB18i
G5UAnRWiQ2AGGaGczhK5czqVg4tbHmmp
=26fF
-----END PGP SIGNATURE-----

--
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: Permissive mode for xace is broken.

[Eamon Walsh]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Stephen Smalley wrote:
>   
>> On Mon, 2008-02-25 at 09:48 -0500, Daniel J Walsh wrote:
>>     
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Stephen Smalley wrote:
>>>       
>>>> On Mon, 2008-02-25 at 09:12 -0500, Stephen Smalley wrote:
>>>>         
>>>>> On Mon, 2008-02-25 at 09:09 -0500, Daniel J Walsh wrote:
>>>>>           
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> If I turn on xserver_object_manager in rawhide and log in as staff_t in
>>>>>> permissive mode, I get all sorts of things failing, which makes writing
>>>>>> policy for it very difficult.  And is very broken.
>>>>>>             
>>>>> Hmmm...as I understood it, XSELinux should follow the kernel's enforcing
>>>>> status by default (i.e. if the kernel is permissive, then so should
>>>>> XSELinux), unless you explicitly configure enforcing= in xorg.conf to
>>>>> specify a different setting for the X server than the kernel.  You are
>>>>> supposed to be able to make the X server permissive w/o making the
>>>>> kernel permissive via xorg configuration, I believe, although I'm not
>>>>> sure that made it into the rawhide xorg yet.
>>>>>           
>>>> Doesn't look like the rawhide xorg server has that support yet.
>>>>
>>>> But it should follow the kernel's enforcing status.  You should see log
>>>> messages with "received setenforce notice (enforcing=...)" in them from
>>>> both dbus and X in either /var/log/messages or /var/log/audit/audit.log.
>>>>
>>>>         
>>> Looking at the code, I do not see security_getenforce() in the code.
>>> Are you saying that this is not necessary, the kernel will return
>>> allowed but generate the AVC?
>>>       
>> Handling of enforcing status is hidden within the userspace AVC in
>> libselinux (libselinux/src/avc*.c).  avc_enforcing stores the current
>> value of the enforcing status and is updated when the kernel generates
>> the setenforce notification.  avc_setenforce is set if the object
>> manager explicitly sets its own enforcing mode to a specific value to
>> override the kernel status.
>>
>>     
>>> And the only one who mentions setenforce in /var/log/audit/audit.log in
>>> dbus not X?
>>>       
>> Hmmm...that's seems like a bug in X then, that it isn't getting the
>> notifications from the kernel (via netlink).
>>
>>     
> Yes XAce seems to be very broken in Rawhide.  Enforcing mode was working
> until I fixed the policy to allow xserver to talk to /selinux and run
> the validation routines.  Now xace is blowing up both in permissive and
> enforcing mode.
>
> Trying to start nm-applet is getting a BadWindow error.
>
> If you update to todays rawhide and try to login in permissive mode,
> metacity and gconf will blow up.
>   

I'll investigate the blowing up today.  I'm puzzled by the BadWindow 
error; permission denials should always be indicated by "BadAccess".  
This may be the bug fixed by the errno patch I posted on Friday.

There is no support for configuring the X server in permissive/enforcing 
in xorg.conf.  You can disable it from xorg.conf, but if it is not 
disabled, it will follow the system setting.  I proposed adding support 
for this to /etc/selinux/config, which was shot down on the list.  I 
have not moved forward with adding a permissive/enforcing switch to Xorg.

The X object manager logs all avc's and status messages (including the 
AVC netlink stuff) through the audit system using libaudit calls 
(audit_log_user_avc_message, etc.)   I disavow all responsibility for 
the messages once they enter libaudit.


-- 
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: Permissive mode for xace is broken.

[Eamon Walsh]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Daniel J Walsh wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Mon, 2008-02-25 at 09:48 -0500, Daniel J Walsh wrote:
>>>       
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Stephen Smalley wrote:
>>>>         
>>>>> On Mon, 2008-02-25 at 09:12 -0500, Stephen Smalley wrote:
>>>>>           
>>>>>> On Mon, 2008-02-25 at 09:09 -0500, Daniel J Walsh wrote:
>>>>>>             
>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA1
>>>>>>>
>>>>>>> If I turn on xserver_object_manager in rawhide and log in as staff_t in
>>>>>>> permissive mode, I get all sorts of things failing, which makes writing
>>>>>>> policy for it very difficult.  And is very broken.
>>>>>>>               
>>>>>> Hmmm...as I understood it, XSELinux should follow the kernel's enforcing
>>>>>> status by default (i.e. if the kernel is permissive, then so should
>>>>>> XSELinux), unless you explicitly configure enforcing= in xorg.conf to
>>>>>> specify a different setting for the X server than the kernel.  You are
>>>>>> supposed to be able to make the X server permissive w/o making the
>>>>>> kernel permissive via xorg configuration, I believe, although I'm not
>>>>>> sure that made it into the rawhide xorg yet.
>>>>>>             
>>>>> Doesn't look like the rawhide xorg server has that support yet.
>>>>>
>>>>> But it should follow the kernel's enforcing status.  You should see log
>>>>> messages with "received setenforce notice (enforcing=...)" in them from
>>>>> both dbus and X in either /var/log/messages or /var/log/audit/audit.log.
>>>>>
>>>>>           
>>>> Looking at the code, I do not see security_getenforce() in the code.
>>>> Are you saying that this is not necessary, the kernel will return
>>>> allowed but generate the AVC?
>>>>         
>>> Handling of enforcing status is hidden within the userspace AVC in
>>> libselinux (libselinux/src/avc*.c).  avc_enforcing stores the current
>>> value of the enforcing status and is updated when the kernel generates
>>> the setenforce notification.  avc_setenforce is set if the object
>>> manager explicitly sets its own enforcing mode to a specific value to
>>> override the kernel status.
>>>       
>>>> And the only one who mentions setenforce in /var/log/audit/audit.log in
>>>> dbus not X?
>>>>         
>>> Hmmm...that's seems like a bug in X then, that it isn't getting the
>>> notifications from the kernel (via netlink).
>>>       
>> Yes XAce seems to be very broken in Rawhide.  Enforcing mode was working
>> until I fixed the policy to allow xserver to talk to /selinux and run
>> the validation routines.  Now xace is blowing up both in permissive and
>> enforcing mode.
>>
>> Trying to start nm-applet is getting a BadWindow error.
>>
>> If you update to todays rawhide and try to login in permissive mode,
>> metacity and gconf will blow up.
>>
>>     
>
> nm-applet --sync
> The program 'nm-applet' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadWindow (invalid Window parameter)'.
>   (Details: serial 228 error_code 3 request_code 2 minor_code 0)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error() function.)
>
>
> This is a serious problem, and needs to be fixed ASAP, or I need to pull
> support for xace from policy.
>   

Here's problem #1, after switching from refpolicy to targeted, reboot 
with full relabel, and setenforce 1.  We'll see what boolean I forgot to 
set.


# ssh moss-charon
Last login: Mon Feb 25 16:36:55 2008 from moss-huskies.epoch.ncsc.mil
/bin/bash: Permission denied
Connection to moss-charon closed.



-- 
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: Permissive mode for xace is broken.

[Eamon Walsh]

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

Eamon Walsh wrote:
> The X object manager logs all avc's and status messages (including the 
> AVC netlink stuff) through the audit system using libaudit calls 
> (audit_log_user_avc_message, etc.)   I disavow all responsibility for 
> the messages once they enter libaudit

It's being black-holed in rawhide.  To see for yourself, add the 
attached patch to the spec file and rebuild the xserver from SRPM.  It 
will tee the avc messages into /var/log/Xorg.0.log.

Also, pull libselinux from upstream.  The BadWindow error may be fixed.

You'll have to report to me what you see in the X server output.  I'm 
seeing tons of avc's: it doesn't appear as though staff_t is even 
getting X permissions allowed.





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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xserver-1.4.99-xselinux-debug.patch --]
[-- Type: text/x-patch; name="xserver-1.4.99-xselinux-debug.patch", Size: 0 bytes --]

Re: Permissive mode for xace is broken.

[Stephen Smalley]

On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
> Eamon Walsh wrote:
> > The X object manager logs all avc's and status messages (including the 
> > AVC netlink stuff) through the audit system using libaudit calls 
> > (audit_log_user_avc_message, etc.)   I disavow all responsibility for 
> > the messages once they enter libaudit
> 
> It's being black-holed in rawhide.  To see for yourself, add the 
> attached patch to the spec file and rebuild the xserver from SRPM.  It 
> will tee the avc messages into /var/log/Xorg.0.log.

Looking at the corresponding code in dbus, I see that dbus is calling
both audit_log_user_avc_message() (if HAVE_LIBAUDIT) and
vsyslog(LOG_INFO...) with the message.

Can you verify that the X server was able to create the audit socket
successfully?

Things that could go wrong:
- X server uses privilege bracketing (switching uids or capabilities)
and lacks the necessary audit capabilities.
- X server shuts down all descriptors _after_ you've opened the audit
socket, thereby closing it down too.
- Policy doesn't allow X server to write audit messages (requires
audit_write capability and netlink_audit_socket perms).

Dan, what policy are you using?  trunk?  or xselinux branch?
I don't think Chris has merged xselinux branch to trunk yet, or that it
is necessarily safe to work from that branch (i.e. things could change
as part of the merge in an incompatible way).

> Also, pull libselinux from upstream.  The BadWindow error may be fixed.
> 
> You'll have to report to me what you see in the X server output.  I'm 
> seeing tons of avc's: it doesn't appear as though staff_t is even 
> getting X permissions allowed.
> 
> 
> 
> 
> 
-- 
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: Permissive mode for xace is broken.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
>> Eamon Walsh wrote:
>>> The X object manager logs all avc's and status messages (including the 
>>> AVC netlink stuff) through the audit system using libaudit calls 
>>> (audit_log_user_avc_message, etc.)   I disavow all responsibility for 
>>> the messages once they enter libaudit
>> It's being black-holed in rawhide.  To see for yourself, add the 
>> attached patch to the spec file and rebuild the xserver from SRPM.  It 
>> will tee the avc messages into /var/log/Xorg.0.log.
> 
> Looking at the corresponding code in dbus, I see that dbus is calling
> both audit_log_user_avc_message() (if HAVE_LIBAUDIT) and
> vsyslog(LOG_INFO...) with the message.
> 
> Can you verify that the X server was able to create the audit socket
> successfully?
> 
> Things that could go wrong:
> - X server uses privilege bracketing (switching uids or capabilities)
> and lacks the necessary audit capabilities.
> - X server shuts down all descriptors _after_ you've opened the audit
> socket, thereby closing it down too.
> - Policy doesn't allow X server to write audit messages (requires
> audit_write capability and netlink_audit_socket perms).
> 
> Dan, what policy are you using?  trunk?  or xselinux branch?
> I don't think Chris has merged xselinux branch to trunk yet, or that it
> is necessarily safe to work from that branch (i.e. things could change
> as part of the merge in an incompatible way).
> 
>> Also, pull libselinux from upstream.  The BadWindow error may be fixed.
>>
>> You'll have to report to me what you see in the X server output.  I'm 
>> seeing tons of avc's: it doesn't appear as though staff_t is even 
>> getting X permissions allowed.
>>
>>
>>
>>
>>
I have merged changes from the xselinux into the Fedora pool.  I am now
seeing AVC messages in the /var/log/audit/audit.log with an unreleased
policy.  My current policy does not generate AVC's with staff_t, but in
permissive mode/without the xserver_object_manager boolean set, lots of
XApps (toolbar apps) with BadWindow.  In enforcing mode with the
xserver_object_manager boolean set they are also failing.  I have
updated to the latest libselinux and am still seeing the problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfED4QACgkQrlYvE4MpobPcQwCguQfD9qHcfDQV+Zy12JqUJREz
RAIAnihuzWBm5dU66RDMHamaHoScH1OJ
=UfCr
-----END PGP SIGNATURE-----

--
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: Permissive mode for xace is broken.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eamon Walsh wrote:
> Eamon Walsh wrote:
>> The X object manager logs all avc's and status messages (including the
>> AVC netlink stuff) through the audit system using libaudit calls
>> (audit_log_user_avc_message, etc.)   I disavow all responsibility for
>> the messages once they enter libaudit
> 
> It's being black-holed in rawhide.  To see for yourself, add the
> attached patch to the spec file and rebuild the xserver from SRPM.  It
> will tee the avc messages into /var/log/Xorg.0.log.
> 
> Also, pull libselinux from upstream.  The BadWindow error may be fixed.
> 
> You'll have to report to me what you see in the X server output.  I'm
> seeing tons of avc's: it doesn't appear as though staff_t is even
> getting X permissions allowed.
> 
> 
> 
> 
> 
My current rawhide policy is available at


http://people.fedoraproject.org/~dwalsh/SELinux/F9/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfEI5AACgkQrlYvE4MpobNueACeLHwWDZVdB9zHEF+oCOx2aDJR
ujEAn17mGB7k26icF3bLpSjY7PxW8PvT
=WmDN
-----END PGP SIGNATURE-----

--
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: Permissive mode for xace is broken.

[Eamon Walsh]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Stephen Smalley wrote:
>   
>> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
>>     
>>> Eamon Walsh wrote:
>>>       
>>>> The X object manager logs all avc's and status messages (including the 
>>>> AVC netlink stuff) through the audit system using libaudit calls 
>>>> (audit_log_user_avc_message, etc.)   I disavow all responsibility for 
>>>> the messages once they enter libaudit
>>>>         
>>> It's being black-holed in rawhide.  To see for yourself, add the 
>>> attached patch to the spec file and rebuild the xserver from SRPM.  It 
>>> will tee the avc messages into /var/log/Xorg.0.log.
>>>       
>> Looking at the corresponding code in dbus, I see that dbus is calling
>> both audit_log_user_avc_message() (if HAVE_LIBAUDIT) and
>> vsyslog(LOG_INFO...) with the message.
>>
>> Can you verify that the X server was able to create the audit socket
>> successfully?
>>
>> Things that could go wrong:
>> - X server uses privilege bracketing (switching uids or capabilities)
>> and lacks the necessary audit capabilities.
>> - X server shuts down all descriptors _after_ you've opened the audit
>> socket, thereby closing it down too.
>> - Policy doesn't allow X server to write audit messages (requires
>> audit_write capability and netlink_audit_socket perms).
>>
>> Dan, what policy are you using?  trunk?  or xselinux branch?
>> I don't think Chris has merged xselinux branch to trunk yet, or that it
>> is necessarily safe to work from that branch (i.e. things could change
>> as part of the merge in an incompatible way).
>>
>>     
>>> Also, pull libselinux from upstream.  The BadWindow error may be fixed.
>>>
>>> You'll have to report to me what you see in the X server output.  I'm 
>>> seeing tons of avc's: it doesn't appear as though staff_t is even 
>>> getting X permissions allowed.
>>>
>>>
>>>
>>>
>>>
>>>       
> I have merged changes from the xselinux into the Fedora pool.  I am now
> seeing AVC messages in the /var/log/audit/audit.log with an unreleased
> policy.  My current policy does not generate AVC's with staff_t, but in
> permissive mode/without the xserver_object_manager boolean set, lots of
> XApps (toolbar apps) with BadWindow.  In enforcing mode with the
> xserver_object_manager boolean set they are also failing.  I have
> updated to the latest libselinux and am still seeing the problem.
>   

I found the source of the BadWindow errors.  I'm going to fix this 
upstream and throw an SRPM patch to Dan so he can test.

Also, I think I'm going to change XQueryPointer() from requring "read" 
to simply "getattr" permission on the device.  I really do think it 
should require "read," but too many things call it and we need to turn 
"read" off to prevent the xspy attack.

Finally, I'm going to try and get the polyinstantiation code for 
properties and selections in before the feature freeze.


-- 
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: Permissive mode for xace is broken.

[Eamon Walsh]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

Joe Nall wrote:
> On Feb 26, 2008, at 8:31 PM, Eamon Walsh wrote:
>   
>> I found the source of the BadWindow errors.  I'm going to fix this  
>> upstream and throw an SRPM patch to Dan so he can test.
>>
>> Also, I think I'm going to change XQueryPointer() from requring  
>> "read" to simply "getattr" permission on the device.  I really do  
>> think it should require "read," but too many things call it and we  
>> need to turn "read" off to prevent the xspy attack.
>>
>> Finally, I'm going to try and get the polyinstantiation code for  
>> properties and selections in before the feature freeze.
>>     
>
> Awesome. Can I get a copy of the patch too?
>
> joe
>   

Attached and selinux list cc'ed.

One more thing: the SELinux extension is part of extmod, so you can do 
this in your xorg.conf if you want to disable it:

Section "Module"
        SubSection "extmod"
		Option "omit SELinux"
        EndSubSection
EndSection


At the present time there is no enforcing/permissive switch for just the 
xserver.


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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: badwindow_fix.patch --]
[-- Type: text/x-patch; name="badwindow_fix.patch", Size: 0 bytes --]

Re: Permissive mode for xace is broken.

[Eamon Walsh]

Stephen Smalley wrote:
> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
>   
>> Eamon Walsh wrote:
>>     
>>> The X object manager logs all avc's and status messages (including the 
>>> AVC netlink stuff) through the audit system using libaudit calls 
>>> (audit_log_user_avc_message, etc.)   I disavow all responsibility for 
>>> the messages once they enter libaudit
>>>       
>> It's being black-holed in rawhide.  To see for yourself, add the 
>> attached patch to the spec file and rebuild the xserver from SRPM.  It 
>> will tee the avc messages into /var/log/Xorg.0.log.
>>     
>
> Looking at the corresponding code in dbus, I see that dbus is calling
> both audit_log_user_avc_message() (if HAVE_LIBAUDIT) and
> vsyslog(LOG_INFO...) with the message.
>   

Should the X server do this also?  Why does it need to be logged twice?

> Can you verify that the X server was able to create the audit socket
> successfully?
>   

Yes, because when I actually install the audit package, things started 
appearing in /var/log/audit/audit.log.  I did not have the audit package 
installed.  Why isn't it redirecting to /var/log/messages in this case?  
This is the behavior I was led to believe would happen, and this is what 
happens with kernel AVC's.

> Things that could go wrong:
> - X server uses privilege bracketing (switching uids or capabilities)
> and lacks the necessary audit capabilities.
> - X server shuts down all descriptors _after_ you've opened the audit
> socket, thereby closing it down too.
> - Policy doesn't allow X server to write audit messages (requires
> audit_write capability and netlink_audit_socket perms).
>   


-- 
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: Permissive mode for xace is broken.

[Stephen Smalley]

On Thu, 2008-02-28 at 13:48 -0500, Eamon Walsh wrote:
> Stephen Smalley wrote:
> > On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
> >   
> >> Eamon Walsh wrote:
> >>     
> >>> The X object manager logs all avc's and status messages (including the 
> >>> AVC netlink stuff) through the audit system using libaudit calls 
> >>> (audit_log_user_avc_message, etc.)   I disavow all responsibility for 
> >>> the messages once they enter libaudit
> >>>       
> >> It's being black-holed in rawhide.  To see for yourself, add the 
> >> attached patch to the spec file and rebuild the xserver from SRPM.  It 
> >> will tee the avc messages into /var/log/Xorg.0.log.
> >>     
> >
> > Looking at the corresponding code in dbus, I see that dbus is calling
> > both audit_log_user_avc_message() (if HAVE_LIBAUDIT) and
> > vsyslog(LOG_INFO...) with the message.
> >   
> 
> Should the X server do this also?  Why does it need to be logged twice?
> 
> > Can you verify that the X server was able to create the audit socket
> > successfully?
> >   
> 
> Yes, because when I actually install the audit package, things started 
> appearing in /var/log/audit/audit.log.  I did not have the audit package 
> installed.  Why isn't it redirecting to /var/log/messages in this case?  
> This is the behavior I was led to believe would happen, and this is what 
> happens with kernel AVC's.

That's what I would expect, but I don't know.  Safest thing would seem
to be to follow dbus' example.  The audit calls there are also
conditionally compiled, so they can be entirely omitted on systems
without libaudit, whereas the system logging is unconditional.

> 
> > Things that could go wrong:
> > - X server uses privilege bracketing (switching uids or capabilities)
> > and lacks the necessary audit capabilities.
> > - X server shuts down all descriptors _after_ you've opened the audit
> > socket, thereby closing it down too.
> > - Policy doesn't allow X server to write audit messages (requires
> > audit_write capability and netlink_audit_socket perms).
> >   
> 
> 
-- 
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: Permissive mode for xace is broken.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Thu, 2008-02-28 at 13:48 -0500, Eamon Walsh wrote:
>> Stephen Smalley wrote:
>>> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
>>>   
>>>> Eamon Walsh wrote:
>>>>     
>>>>> The X object manager logs all avc's and status messages (including the 
>>>>> AVC netlink stuff) through the audit system using libaudit calls 
>>>>> (audit_log_user_avc_message, etc.)   I disavow all responsibility for 
>>>>> the messages once they enter libaudit
>>>>>       
>>>> It's being black-holed in rawhide.  To see for yourself, add the 
>>>> attached patch to the spec file and rebuild the xserver from SRPM.  It 
>>>> will tee the avc messages into /var/log/Xorg.0.log.
>>>>     
>>> Looking at the corresponding code in dbus, I see that dbus is calling
>>> both audit_log_user_avc_message() (if HAVE_LIBAUDIT) and
>>> vsyslog(LOG_INFO...) with the message.
>>>   
>> Should the X server do this also?  Why does it need to be logged twice?
>>
>>> Can you verify that the X server was able to create the audit socket
>>> successfully?
>>>   
>> Yes, because when I actually install the audit package, things started 
>> appearing in /var/log/audit/audit.log.  I did not have the audit package 
>> installed.  Why isn't it redirecting to /var/log/messages in this case?  
>> This is the behavior I was led to believe would happen, and this is what 
>> happens with kernel AVC's.
> 
> That's what I would expect, but I don't know.  Safest thing would seem
> to be to follow dbus' example.  The audit calls there are also
> conditionally compiled, so they can be entirely omitted on systems
> without libaudit, whereas the system logging is unconditional.
> 
>>> Things that could go wrong:
>>> - X server uses privilege bracketing (switching uids or capabilities)
>>> and lacks the necessary audit capabilities.
>>> - X server shuts down all descriptors _after_ you've opened the audit
>>> socket, thereby closing it down too.
>>> - Policy doesn't allow X server to write audit messages (requires
>>> audit_write capability and netlink_audit_socket perms).
>>>   
>>
dbus is not a setuid application so when it runs in userspace it does
not have the right to send an auditmessage.  When it gets a reload
policy, the user space dbus program sends the message to syslog.  I
don't think X needs to do this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfHBMgACgkQrlYvE4MpobOnBACgqabWxmdBqQfRbK9MJ8SxoB1U
h3kAoNMQRNLtcv6z7Jo8bBCDdxr8ab1R
=HuVz
-----END PGP SIGNATURE-----

--
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: Permissive mode for xace is broken.

[Steve Grubb]

On Thursday 28 February 2008 13:51:05 Stephen Smalley wrote:
> On Thu, 2008-02-28 at 13:48 -0500, Eamon Walsh wrote:
> > Stephen Smalley wrote:
> > > On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
> > >> Eamon Walsh wrote:
> > >>> The X object manager logs all avc's and status messages (including
> > >>> the AVC netlink stuff) through the audit system using libaudit calls
> > >>> (audit_log_user_avc_message, etc.)

Please tell me they have different record types. Also do you have any samples 
that we can look over to make sure they conform?


> > > Can you verify that the X server was able to create the audit socket
> > > successfully?
> >
> > Yes, because when I actually install the audit package, things started
> > appearing in /var/log/audit/audit.log.  I did not have the audit package
> > installed.  Why isn't it redirecting to /var/log/messages in this case?

It should be if you have audit enabled. Perhaps you didn't boot with audit=1?

-Steve

--
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: Permissive mode for xace is broken.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve Grubb wrote:
> On Thursday 28 February 2008 13:51:05 Stephen Smalley wrote:
>> On Thu, 2008-02-28 at 13:48 -0500, Eamon Walsh wrote:
>>> Stephen Smalley wrote:
>>>> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
>>>>> Eamon Walsh wrote:
>>>>>> The X object manager logs all avc's and status messages (including
>>>>>> the AVC netlink stuff) through the audit system using libaudit calls
>>>>>> (audit_log_user_avc_message, etc.)
> 
> Please tell me they have different record types. Also do you have any samples 
> that we can look over to make sure they conform?
> 
> 
>>>> Can you verify that the X server was able to create the audit socket
>>>> successfully?
>>> Yes, because when I actually install the audit package, things started
>>> appearing in /var/log/audit/audit.log.  I did not have the audit package
>>> installed.  Why isn't it redirecting to /var/log/messages in this case?
> 
> It should be if you have audit enabled. Perhaps you didn't boot with audit=1?
> 
> -Steve

type=USER_AVC msg=audit(1204228505.703:107): user pid=3744 uid=0
auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
msg='avc:  denied  { read } for request=X11:QueryPointer comm=mono
xdevice="Virtual core pointer"
scontext=unconfined_u:unconfined_r:mono_t:s0
tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=x_device
: exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfHKNAACgkQrlYvE4MpobPgrgCcDbVf45Tk9I7QrzbQD5OPeVqP
CE4AnA4DP3V68X7WV01AQVE1VseYKfV8
=YrCL
-----END PGP SIGNATURE-----

--
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: Permissive mode for xace is broken.

[Eamon Walsh]

Steve Grubb wrote:
> On Thursday 28 February 2008 13:51:05 Stephen Smalley wrote:
>   
>> On Thu, 2008-02-28 at 13:48 -0500, Eamon Walsh wrote:
>>     
>>> Stephen Smalley wrote:
>>>       
>>>> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
>>>>         
>>>>> Eamon Walsh wrote:
>>>>>           
>>>>>> The X object manager logs all avc's and status messages (including
>>>>>> the AVC netlink stuff) through the audit system using libaudit calls
>>>>>> (audit_log_user_avc_message, etc.)
>>>>>>             
>
> Please tell me they have different record types. Also do you have any samples 
> that we can look over to make sure they conform?
>   

The  libselinux logging callback has support for four message types: 
"avc", "info", "warn", and "error".  What are the libaudit codes 
associated with these?  I see USER_AVC and SELINUX_USER_ERR.  The reload 
message is not really an "error."

Samples attached.  The avc messages generated by the X server have 
X-specific fields in them:

request (X protocol request name)
comm (program name)
client (X client number)
xdevice (name of X device)
resid (X resource ID)
restype (X resource type)
event (X event type)
property (X property name)
selection (X selection name)
extension (X extension name)

If you want these field names changed, for example prefixed with "x", 
please let me know.


>
>   
>>>> Can you verify that the X server was able to create the audit socket
>>>> successfully?
>>>>         
>>> Yes, because when I actually install the audit package, things started
>>> appearing in /var/log/audit/audit.log.  I did not have the audit package
>>> installed.  Why isn't it redirecting to /var/log/messages in this case?
>>>       
>
> It should be if you have audit enabled. Perhaps you didn't boot with audit=1?
>   

No, I didn't have this flag set.

-- 
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: Permissive mode for xace is broken.

[Eamon Walsh]

Steve Grubb wrote:
> On Thursday 28 February 2008 13:51:05 Stephen Smalley wrote:
>   
>> On Thu, 2008-02-28 at 13:48 -0500, Eamon Walsh wrote:
>>     
>>> Stephen Smalley wrote:
>>>       
>>>> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
>>>>         
>>>>> Eamon Walsh wrote:
>>>>>           
>>>>>> The X object manager logs all avc's and status messages (including
>>>>>> the AVC netlink stuff) through the audit system using libaudit calls
>>>>>> (audit_log_user_avc_message, etc.)
>>>>>>             
>
> Please tell me they have different record types. Also do you have any samples 
> that we can look over to make sure they conform?
>   

type=USER_AVC msg=audit(1204226161.048:268): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { read } for request=X11:QueryPointer comm=/usr/libexec/at-spi-registryd xdevice="Virtual core pointer" scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226225.513:271): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { force_cursor } for request=X11:GrabPointer comm=metacity xdevice="Virtual core pointer" scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226228.221:272): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { get_property } for request=X11:GetProperty comm=/usr/lib/firefox-3.0b4pre/firefox resid=480002d restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226228.221:273): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { list_child } for request=X11:QueryTree comm=/usr/lib/firefox-3.0b4pre/firefox resid=480002d restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226245.176:274): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { send } for request=X11:SendEvent comm=gnome-panel resid=4800006 restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226245.176:275): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { send } for request=X11:SendEvent comm=gnome-panel event=X11:ClientMessage scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_client_xevent_t:s0 tclass=x_synthetic_event : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226245.186:276): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { getattr } for request=X11:GetWindowAttributes comm=gnome-screensaver resid=480002e restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226245.190:277): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for request=X11:ChangeWindowAttributes comm=gnome-screensaver resid=480002e restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226245.259:278): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { read } for request=X11:GetProperty comm=/usr/libexec/gnome-settings-daemon property=WM_NAME scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_default_xproperty_t:s0 tclass=x_property : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226247.388:279): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for  comm=gnome-screensaver event=X11:DestroyNotify scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_manage_xevent_t:s0 tclass=x_event : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226293.995:282): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { use } for request=GLX:QueryVersion comm=/usr/libexec/gnome-screensaver-gl-helper extension=GLX scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:accelgraphics_xext_t:s0 tclass=x_extension : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226294.590:283): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { send } for request=X11:SendEvent comm=/usr/libexec/gnome-screensaver-dialog event=X11:SelectionNotify scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_default_xevent_t:s0 tclass=x_synthetic_event : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226336.290:287): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for  comm=gnome-screensaver event=X11:PropertyNotify scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_property_xevent_t:s0 tclass=x_event : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226336.502:288): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { hide } for request=X11:UnmapWindow comm=gnome-panel resid=4800006 restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226336.503:289): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { manage } for request=X11:ReparentWindow comm=gnome-panel resid=4800006 restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226336.754:292): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for  comm=mono scontext=staff_u:staff_r:staff_mono_t:s0 tcontext=staff_u:object_r:staff_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226336.754:293): user pid=21267 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for  comm=mono event=X11:DestroyNotify scontext=staff_u:staff_r:staff_mono_t:s0 tcontext=staff_u:object_r:staff_manage_xevent_t:s0 tclass=x_event : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226339.514:295): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { read } for request=X11:QueryPointer comm=/usr/libexec/gdm-simple-greeter xdevice="Virtual core pointer" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226460.698:307): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { read } for request=X11:QueryPointer comm=gnome-session xdevice="Virtual core pointer" scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226460.807:308): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { use } for request=XTEST:GrabControl comm=/usr/libexec/at-spi-registryd extension=XTEST scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:debug_xext_t:s0 tclass=x_extension : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226466.997:312): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for request=X11:ChangeWindowAttributes comm=mono resid=1400006 restype=WINDOW scontext=staff_u:staff_r:staff_mono_t:s0 tcontext=staff_u:object_r:staff_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226466.997:313): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { getattr } for request=X11:GetWindowAttributes comm=mono resid=1400006 restype=WINDOW scontext=staff_u:staff_r:staff_mono_t:s0 tcontext=staff_u:object_r:staff_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226466.999:314): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { list_child } for request=X11:QueryTree comm=mono resid=1400006 restype=WINDOW scontext=staff_u:staff_r:staff_mono_t:s0 tcontext=staff_u:object_r:staff_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226467.000:315): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { get_property } for request=X11:GetProperty comm=mono resid=1400006 restype=WINDOW scontext=staff_u:staff_r:staff_mono_t:s0 tcontext=staff_u:object_r:staff_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226467.000:316): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { read } for request=X11:GetProperty comm=mono property=_XSETTINGS_SETTINGS scontext=staff_u:staff_r:staff_mono_t:s0 tcontext=staff_u:object_r:staff_default_xproperty_t:s0 tclass=x_property : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226467.025:317): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { get_property } for request=X11:GetProperty comm=/usr/libexec/gnome-settings-daemon resid=4400001 restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226467.026:318): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { read } for request=X11:GetProperty comm=/usr/libexec/gnome-settings-daemon property=WM_NAME scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_default_xproperty_t:s0 tclass=x_property : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226467.027:319): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { getattr } for request=X11:GetWindowAttributes comm=/usr/libexec/gnome-settings-daemon resid=4400001 restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226467.028:320): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for request=X11:ChangeWindowAttributes comm=/usr/libexec/gnome-settings-daemon resid=4400001 restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226467.067:321): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { read } for request=X11:QueryPointer comm=mono xdevice="Virtual core pointer" scontext=staff_u:staff_r:staff_mono_t:s0 tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=x_device : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226467.118:322): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for  comm=/usr/libexec/gnome-settings-daemon event=X11:PropertyNotify scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_property_xevent_t:s0 tclass=x_event : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226467.599:324): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { list_child } for request=X11:QueryTree comm=gnome-screensaver resid=4400001 restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226468.841:326): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for  comm=/usr/libexec/gnome-settings-daemon event=X11:CreateNotify scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_manage_xevent_t:s0 tclass=x_event : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226468.847:327): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { hide } for request=X11:UnmapWindow comm=gnome-panel resid=440000c restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226468.847:328): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { manage } for request=X11:ReparentWindow comm=gnome-panel resid=440000c restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226468.850:329): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { send } for request=X11:SendEvent comm=gnome-panel resid=440000c restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226468.850:330): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { send } for request=X11:SendEvent comm=gnome-panel event=X11:ClientMessage scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_client_xevent_t:s0 tclass=x_synthetic_event : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226468.859:331): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { setattr } for request=X11:ConfigureWindow comm=gnome-panel resid=440000c restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226468.860:332): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { set_property } for request=X11:ChangeProperty comm=gnome-panel resid=440000c restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226468.860:333): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { show } for request=X11:MapWindow comm=gnome-panel resid=440000c restype=WINDOW scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_t:s0 tclass=x_drawable : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226468.861:334): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for  comm=gnome-screensaver event=X11:Expose scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:staff_mono_default_xevent_t:s0 tclass=x_event : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
type=USER_AVC msg=audit(1204226482.060:338): user pid=21710 uid=0 auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 msg='avc:  denied  { receive } for  comm=mono event=X11:DestroyNotify scontext=staff_u:staff_r:staff_mono_t:s0 tcontext=staff_u:object_r:staff_manage_xevent_t:s0 tclass=x_event : exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'



-- 
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: Permissive mode for xace is broken.

[Steve Grubb]

On Thursday 28 February 2008 21:02:28 Eamon Walsh wrote:
> Steve Grubb wrote:
> > On Thursday 28 February 2008 13:51:05 Stephen Smalley wrote:
> >> On Thu, 2008-02-28 at 13:48 -0500, Eamon Walsh wrote:
> >>> Stephen Smalley wrote:
> >>>> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
> >>>>> Eamon Walsh wrote:
> >>>>>> The X object manager logs all avc's and status messages (including
> >>>>>> the AVC netlink stuff) through the audit system using libaudit calls
> >>>>>> (audit_log_user_avc_message, etc.)
> >
> > Please tell me they have different record types. Also do you have any
> > samples that we can look over to make sure they conform?
>
> type=USER_AVC msg=audit(1204226161.048:268): user pid=21267 uid=0
> auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
> msg='avc:  denied  { read } for request=X11:QueryPointer
> comm=/usr/libexec/at-spi-registryd xdevice="Virtual core pointer"
> scontext=staff_u:staff_r:staff_t:s0
> tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=x_device :
> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'

comm & xdevice are not escaped the right way. exe is. The audit utilities are 
expecting the comm field to be comm="/usr/libexec/at-spi-registryd" in this 
case. The standard has been untrusted fields have " " enclosing the field. 
Whenever there is a space, double quote, or control character, its ASCII HEX 
encoded with no quotes. xdevice is not a field that the audit system knows 
about, so we could do something different with it, but comm is known for a 
long time and has to follow the standards.

Also, is there any information about who caused the event? uid, auid, gid? 
Even though this was a denied action, what is the results? Were they 
successful (permissive) or was it really a failed and denied request?

Would it make sense to fill in the workspace:window information for the 
terminal? If X is being used remotely, is the addr & hostname fields correct?

That's the only things I notice at this point.

-Steve

--
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: Permissive mode for xace is broken.

[Eamon Walsh]

Steve Grubb wrote:
> On Thursday 28 February 2008 21:02:28 Eamon Walsh wrote:
>   
>> Steve Grubb wrote:
>>     
>>> On Thursday 28 February 2008 13:51:05 Stephen Smalley wrote:
>>>       
>>>> On Thu, 2008-02-28 at 13:48 -0500, Eamon Walsh wrote:
>>>>         
>>>>> Stephen Smalley wrote:
>>>>>           
>>>>>> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
>>>>>>             
>>>>>>> Eamon Walsh wrote:
>>>>>>>               
>>>>>>>> The X object manager logs all avc's and status messages (including
>>>>>>>> the AVC netlink stuff) through the audit system using libaudit calls
>>>>>>>> (audit_log_user_avc_message, etc.)
>>>>>>>>                 
>>> Please tell me they have different record types. Also do you have any
>>> samples that we can look over to make sure they conform?
>>>       
>> type=USER_AVC msg=audit(1204226161.048:268): user pid=21267 uid=0
>> auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
>> msg='avc:  denied  { read } for request=X11:QueryPointer
>> comm=/usr/libexec/at-spi-registryd xdevice="Virtual core pointer"
>> scontext=staff_u:staff_r:staff_t:s0
>> tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=x_device :
>> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
>>     
>
> comm & xdevice are not escaped the right way. exe is. The audit utilities are 
> expecting the comm field to be comm="/usr/libexec/at-spi-registryd" in this 
> case. The standard has been untrusted fields have " " enclosing the field. 
> Whenever there is a space, double quote, or control character, its ASCII HEX 
> encoded with no quotes. xdevice is not a field that the audit system knows 
> about, so we could do something different with it, but comm is known for a 
> long time and has to follow the standards.
>   

Why can't libaudit automatically perform this escaping?  That way we 
avoid promulgating this "standard" into every caller of libaudit.

If everything is going to be name-value based, then I want a libaudit 
function that takes a list of name/value pairs.


> Also, is there any information about who caused the event? uid, auid, gid? 
> Even though this was a denied action, what is the results? Were they 
> successful (permissive) or was it really a failed and denied request?
>   

I don't understand this last part with the result of the action.  How am 
I supposed to specify this?

I need to modify libselinux (again) to support all of this extra uid and 
hostname stuff getting passed into the logging callback.


> Would it make sense to fill in the workspace:window information for the 
> terminal? If X is being used remotely, is the addr & hostname fields correct?
>   

The X server has a terminal that it runs on, /dev/tty7 or whatever.  The 
desktop workspaces and gnome-terminal/xterm pseudo-tty's are external to 
the X server and it doesn't know about them.


> That's the only things I notice at this point.
>
> -Steve
>
> --
> 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: Permissive mode for xace is broken.

[Steve G]

----- Original Message ----
> From: Eamon Walsh <ewalsh@tycho.nsa.gov>
> To: Steve Grubb <sgrubb@redhat.com>
> Cc: Stephen Smalley <sds@tycho.nsa.gov>; Daniel J Walsh <dwalsh@redhat.com>; SE Linux <selinux@tycho.nsa.gov>
> Sent: Wednesday, March 19, 2008 11:56:00 PM
> Subject: Re: Permissive mode for xace is broken.
> 
> Steve Grubb wrote:
> > On Thursday 28 February 2008 21:02:28 Eamon Walsh wrote:
> >   
> >> Steve Grubb wrote:
> >>     
> >>> On Thursday 28 February 2008 13:51:05 Stephen Smalley wrote:
> >>>       
> >>>> On Thu, 2008-02-28 at 13:48 -0500, Eamon Walsh wrote:
> >>>>         
> >>>>> Stephen Smalley wrote:
> >>>>>           
> >>>>>> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
> >>>>>>             
> >>>>>>> Eamon Walsh wrote:
> >>>>>>>               
> >>>>>>>> The X object manager logs all avc's and status messages (including
> >>>>>>>> the AVC netlink stuff) through the audit system using libaudit calls
> >>>>>>>> (audit_log_user_avc_message, etc.)
> >>>>>>>>                 
> >>> Please tell me they have different record types. Also do you have any
> >>> samples that we can look over to make sure they conform?
> >>>       
> >> type=USER_AVC msg=audit(1204226161.048:268): user pid=21267 uid=0
> >> auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
> >> msg='avc:  denied  { read } for request=X11:QueryPointer
> >> comm=/usr/libexec/at-spi-registryd xdevice="Virtual core pointer"
> >> scontext=staff_u:staff_r:staff_t:s0
> >> tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=x_device :
> >> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
> >>     
> >
> > comm & xdevice are not escaped the right way. exe is. The audit utilities are 
> > expecting the comm field to be comm="/usr/libexec/at-spi-registryd" in this 
> > case. The standard has been untrusted fields have " " enclosing the field. 
> > Whenever there is a space, double quote, or control character, its ASCII HEX 
> > encoded with no quotes. xdevice is not a field that the audit system knows 
> > about, so we could do something different with it, but comm is known for a 
> > long time and has to follow the standards.
> >   
> 
> Why can't libaudit automatically perform this escaping?

Well, it could. However, this is the API that you currently have:

extern int audit_log_user_avc_message(int audit_fd, int type,
        const char *message, const char *hostname, const char *addr,
        const char *tty, uid_t uid);

The whole avc from msg=  up to the exe= statement comes from libselinux. So, libselinux has to do the escaping unless we build a better API for selinux use. I could probably expose the function that does the escaping, but I had really wanted to try to maintain some consistency in the event by API.


>  That way we avoid promulgating this "standard" into every caller of libaudit.
> 
> If everything is going to be name-value based, then I want a libaudit 
> function that takes a list of name/value pairs.

SE Linux is the only user of the audit system that does not follow the name=value standard. Would you (and the community) really be willing to convert selinux over to that if we have the API for it?  Do you have any suggestions about how you'd like to see the new API implemented?


> > Also, is there any information about who caused the event? uid, auid, gid? 
> > Even though this was a denied action, what is the results? Were they 
> > successful (permissive) or was it really a failed and denied request?
> >   
> 
> I don't understand this last part with the result of the action.  How am 
> I supposed to specify this?

res=0 for failed and res=1 for success even though the action was denied. Admittedly, the audit avc API does not require this from SE Linux, but I could fix that if we change the API to something around name value pairs.


> I need to modify libselinux (again) to support all of this extra uid and 
> hostname stuff getting passed into the logging callback.

Yes, CAPP and other CC protection profiles require that sufficient information be logged to determine who did the action that was denied or granted. 

 
> > Would it make sense to fill in the workspace:window information for the 
> > terminal? If X is being used remotely, is the addr & hostname fields correct?
> >   
> 
> The X server has a terminal that it runs on, /dev/tty7 or whatever.  The 
> desktop workspaces and gnome-terminal/xterm pseudo-tty's are external to 
> the X server and it doesn't know about them.

So, should we also make a new field that logs the workspace:window that a request came from?

Thanks,
-Steve





      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

--
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: Permissive mode for xace is broken.

[Stephen Smalley]

On Mon, 2008-03-24 at 08:55 -0700, Steve G wrote:
> 
> ----- Original Message ----
> > From: Eamon Walsh <ewalsh@tycho.nsa.gov>
> > To: Steve Grubb <sgrubb@redhat.com>
> > Cc: Stephen Smalley <sds@tycho.nsa.gov>; Daniel J Walsh <dwalsh@redhat.com>; SE Linux <selinux@tycho.nsa.gov>
> > Sent: Wednesday, March 19, 2008 11:56:00 PM
> > Subject: Re: Permissive mode for xace is broken.
> > 
> > Steve Grubb wrote:
> > > On Thursday 28 February 2008 21:02:28 Eamon Walsh wrote:
> > >   
> > >> Steve Grubb wrote:
> > >>     
> > >>> On Thursday 28 February 2008 13:51:05 Stephen Smalley wrote:
> > >>>       
> > >>>> On Thu, 2008-02-28 at 13:48 -0500, Eamon Walsh wrote:
> > >>>>         
> > >>>>> Stephen Smalley wrote:
> > >>>>>           
> > >>>>>> On Mon, 2008-02-25 at 20:12 -0500, Eamon Walsh wrote:
> > >>>>>>             
> > >>>>>>> Eamon Walsh wrote:
> > >>>>>>>               
> > >>>>>>>> The X object manager logs all avc's and status messages (including
> > >>>>>>>> the AVC netlink stuff) through the audit system using libaudit calls
> > >>>>>>>> (audit_log_user_avc_message, etc.)
> > >>>>>>>>                 
> > >>> Please tell me they have different record types. Also do you have any
> > >>> samples that we can look over to make sure they conform?
> > >>>       
> > >> type=USER_AVC msg=audit(1204226161.048:268): user pid=21267 uid=0
> > >> auid=4294967295 subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
> > >> msg='avc:  denied  { read } for request=X11:QueryPointer
> > >> comm=/usr/libexec/at-spi-registryd xdevice="Virtual core pointer"
> > >> scontext=staff_u:staff_r:staff_t:s0
> > >> tcontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 tclass=x_device :
> > >> exe="/usr/bin/Xorg" (sauid=0, hostname=?, addr=?, terminal=?)'
> > >>     
> > >
> > > comm & xdevice are not escaped the right way. exe is. The audit utilities are 
> > > expecting the comm field to be comm="/usr/libexec/at-spi-registryd" in this 
> > > case. The standard has been untrusted fields have " " enclosing the field. 
> > > Whenever there is a space, double quote, or control character, its ASCII HEX 
> > > encoded with no quotes. xdevice is not a field that the audit system knows 
> > > about, so we could do something different with it, but comm is known for a 
> > > long time and has to follow the standards.
> > >   
> > 
> > Why can't libaudit automatically perform this escaping?
> 
> Well, it could. However, this is the API that you currently have:
> 
> extern int audit_log_user_avc_message(int audit_fd, int type,
>         const char *message, const char *hostname, const char *addr,
>         const char *tty, uid_t uid);
> 
> The whole avc from msg=  up to the exe= statement comes from libselinux. So, libselinux has to do the escaping unless we build a better API for selinux use. I could probably expose the function that does the escaping, but I had really wanted to try to maintain some consistency in the event by API.
> 
> 
> >  That way we avoid promulgating this "standard" into every caller of libaudit.
> > 
> > If everything is going to be name-value based, then I want a libaudit 
> > function that takes a list of name/value pairs.
> 
> SE Linux is the only user of the audit system that does not follow the name=value standard. Would you (and the community) really be willing to convert selinux over to that if we have the API for it?  Do you have any suggestions about how you'd like to see the new API implemented?

When the topic last came up on list, we weren't opposed to converting to
the name=value model, just cautious about not breaking userspace in the
process.   We don't want users suddenly finding that audit2allow,
setroubleshoot, setools, etc suddenly stop working over night.  And that
isn't so far fetched - Fedora pushes new upstream kernels as updates to
old releases w/o any corresponding userland updates, which has caused us
breakage in the past, and akpm specifically tests new kernels on ancient
Fedora releases to see if anything breaks.

As I recall, we even agreed on field names for the avc fields during the
prior thread.  But no one followed up with actual patches to make it
happen.

-- 
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: Permissive mode for xace is broken.

[Steve Grubb]

On Monday 24 March 2008 15:59:05 Stephen Smalley wrote:
> > SE Linux is the only user of the audit system that does not follow the
> > name=value standard. Would you (and the community) really be willing to
> > convert selinux over to that if we have the API for it?  Do you have any
> > suggestions about how you'd like to see the new API implemented?
>
> When the topic last came up on list, we weren't opposed to converting to
> the name=value model, just cautious about not breaking userspace in the
> process.

Sure. Completely understandable.


> As I recall, we even agreed on field names for the avc fields during the
> prior thread.  But no one followed up with actual patches to make it
> happen.

On the audit side, I implemented what we agreed on. It creates 2 fake names 
for use with values (seresult & seperm). At some point, I would recommend 
that the tools experiment with switching over to the auparse library. If that 
happens, then we can change the actual format since auparse is already 
providing the illusion of name=value for all of selinux.

I recommend experimenting with switching over for a couple other reasons. At 
some point we'll start zipping the logs. That will break existing tools 
unless they are gzip aware. And people have been talking about adding 
database support for audit records. If people store events that way, we'll 
have auparse updated to extract events. Its yet another hurdle for the tools 
doing their own parsing.

This isn't likely to happen for another month or two so there is time to 
experiment. What I am concerned about right now, though, is what to do about 
user space AVCs since that is needing some work.  :)

-Steve


--
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: Permissive mode for xace is broken.

[Eamon Walsh]

Steve G wrote:
> Well, it could. However, this is the API that you currently have:
>   

API can always be changed or augmented.  For heaven's sake, the man page 
for "audit_log_user_semanage_message" isn't even spelled correctly right 
now.

> extern int audit_log_user_avc_message(int audit_fd, int type,
>         const char *message, const char *hostname, const char *addr,
>         const char *tty, uid_t uid);
>
> The whole avc from msg=  up to the exe= statement comes from libselinux. So, libselinux has to do the escaping unless we build a better API for selinux use. I could probably expose the function that does the escaping, but I had really wanted to try to maintain some consistency in the event by API.
>   

I would like to see an API that takes an array of struct { name, value 
}, or a variadic (name, value, name, value...).  I think this would be 
far more flexible than the current situation where libaudit functions 
are being defined that take 10, 15, or more parameters.  Furthermore, 
libaudit would handle all escaping of these values according to whatever 
it's format du jour is.  Let's please not start

I realize that this API would be more open ended since it would not 
hardcode specific name/value pairs being passed in, which is what the 
current set of functions are attempting to do with their fixed 
arguments.  But this could be handled some other way, by printing out a 
warning in the logs, doing an assert in the code, or returning an error 
condition if the criteria ones are missing.  Or just doing question 
marks like the current implementation.  Which you're going to have to do 
anyway, because as I have pointed out, not all machines have IP 
addresses or hostnames and not all programs have terminals.

I also made a suggestion earlier about cleaning up the taxonomy of audit 
fields, perhaps by using namespacing such as "selinux.perms, 
selinux.result" etc.

Finally, a good place to start might be to start putting a version 
number field into the messages.  The version number could be bumped for 
each change to the format or fields.


>
>   
>>  That way we avoid promulgating this "standard" into every caller of libaudit.
>>
>> If everything is going to be name-value based, then I want a libaudit 
>> function that takes a list of name/value pairs.
>>     
>
> SE Linux is the only user of the audit system that does not follow the name=value standard. Would you (and the community) really be willing to convert selinux over to that if we have the API for it?  Do you have any suggestions about how you'd like to see the new API implemented?
>
>
>   
>>> Also, is there any information about who caused the event? uid, auid, gid? 
>>> Even though this was a denied action, what is the results? Were they 
>>> successful (permissive) or was it really a failed and denied request?
>>>   
>>>       
>> I don't understand this last part with the result of the action.  How am 
>> I supposed to specify this?
>>     
>
> res=0 for failed and res=1 for success even though the action was denied. Admittedly, the audit avc API does not require this from SE Linux, but I could fix that if we change the API to something around name value pairs.
>   


OK.

>
>   
>> I need to modify libselinux (again) to support all of this extra uid and 
>> hostname stuff getting passed into the logging callback.
>>     
>
> Yes, CAPP and other CC protection profiles require that sufficient information be logged to determine who did the action that was denied or granted. 
>
>  
>   
>>> Would it make sense to fill in the workspace:window information for the 
>>> terminal? If X is being used remotely, is the addr & hostname fields correct?
>>>   
>>>       
>> The X server has a terminal that it runs on, /dev/tty7 or whatever.  The 
>> desktop workspaces and gnome-terminal/xterm pseudo-tty's are external to 
>> the X server and it doesn't know about them.
>>     
>
> So, should we also make a new field that logs the workspace:window that a request came from?
>   

A request does not come from a window.  A request comes from a process.  
The process comm name is already in the message, and the PID of the 
process is also known.  For remote connections, the address and hostname 
are known and can be logged (with some API changes as I mentioned).

I think there's some misunderstanding here about the workspaces, so let 
me try to explain this in more detail.  There is no such thing as a 
"workspace" in the X Window System.   The concept of a workspace is 
completely internal to the metacity window manager.  When you switch 
workspaces, what actually happens is that metacity hides all the windows 
on your screen and then shows a new set of windows.  The only thing the 
X server sees is the requests that are coming in to hide and show 
windows.  There is no workspace information in any X protocol 
requests.   It is _not possible_ for me to log a workspace from the X 
server.


> Thanks,
> -Steve
>
>
>
>
>
>       ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page. 
> http://www.yahoo.com/r/hs
>
>   


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