Re: Tonights rawhide contains a fix to stop xspy.

[Daniel J Walsh <dwalsh@redhat.com>]

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

Eamon Walsh wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Eamon Walsh wrote:
>>> Daniel J Walsh wrote:
>>> Basically if you turn on xserver_object_manager boolean, no applications
>>> will be allowed to read the x_device.  This stops xspy as you said dead
>>> in its tracks,  but some other applications start to get AVC's around
>>> querypointer, and eventually I hung the server.  You mentioned in
>>> another email, that you were going to change the querypointer to a
>>> getattr rather then a read, I think this is necessary, to make this
>>> work.
>>>  
>>>> I have attached a patch that will do this.  There is another request,
>>>> XKEYBOARD:GetState, that also requires read and I've noticed that
>>>> gnome-settings-daemon is calling it (see below).  If you want to drop
>>>> that down to getattr too, let me know; it doesn't look like it returns
>>>> the whole keyboard like XQueryKeymap does, however both it and
>>>> XQueryPointer return the mouse buttons and the modifier keys (shift,
>>>> alt, ctrl, etc.).  Long-term we really need to get applications to stop
>>>> calling these.
>>
>> Is there any way to differentiate the mouse from the keyboard, why are
>> the the same type?
> 
> The idea behind the PAM work is to relabel the devices at login time.
> It's kind of a moot point though because XQueryPointer returns both
> mouse and keyboard state and should technically require read permission
> on both devices.
>
Ok.

>> Can you get this patch upstream, it is a lot easier
>> to get it into rawhide that way.
> 
> The patch is upstream now, with a big /*XXX*/ on it.  Tom London's
> compiz issues are fixed as well.
> 
>
I already wrote a reply to this once, but the X Controls hung my
machine.  So this is good news.

>>
>> Open bugzilla's on any you find, is the best way to get it fixed.
>>
> 
> Rest assured I will.
> 
>>>> "Manage" permission on devices is another can of worms you may care to
>>>> open at some point.  Anyone with that can remap the keys or do other
>>>> things that affect the device globally.
>>>> The other AVC's I'm getting are from interactions between staff_mono
>>>> and
>>>> staff.  I believe that this the result of a small application such as
>>>> the clock or load graph being staff_mono_t, running inside gnome-panel
>>>> which is staff_t.  This is the type of thing I was trying to solve with
>>>> the 4-argument templates that allowed some permissions among the entire
>>>> "role's" windows (however manage was not one of them).
>> Yes this is one of the reasons that I like the ability to extend
>> contexts so all privs of staff_t are inherited by staff_mono_t plus the
>> exec checks.
>>
>> staff_mono_t == staff_t + execmem execstack;
> 
> This would be more than simple inheritance though.  This would be
> implicitly granting staff_mono_t and staff_t permissions on each other
> as well.
> 
I am using the staff_usertype attribute for the "isa" type domains.

And basically writing

allow staff_usertype staff_usertype:* *;

So we need to extend this to the X Controls.
>>
>> I think we are going to need an interface that says one domain can play
>> communicate with another domain, sort of the dbus_chat type interfaces.
> 
> This or the inheritance thing will be necessary, yes, until a better
> handle is gotten on the interaction issues.
>
Right this inheritance works for "isa" domains (mono and java) but will
not work if we want to isolate nsplugin_t or staff_firefox_t.  So we
will need to figure out the minimal communication needed between the
confined X-Application and the XYZ_usertype.

> Have you considered starting out by supporting a simpler desktop
> environment, such as XFCE?

No.  I want to get stuff that is useful to the larger community.  What
low hanging fruit can I grab to help out unconfined users on a
gnome/gtk/gconf/metacity/compiz platform.  I will leave the XFCE to MLS
people who are trying to prevent malicious information flow.

Can I prevent all apps from sniffing passwords?
Can I prevent all nsplugin_t from putting up a login screen?  Can I
prevent it from writing anywhere but to a window owned by firefox_t?

Other than preventing read of x_device_t, is there something else we
need to do to prevent one app from listing for keyboard input of the
focus application?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfIDf8ACgkQrlYvE4MpobO9DACfQndDrWvCDsguZyNc6bdSIf0O
E8IAoOfaMNZuRoN/sfhq9Kibypyg2l7N
=3ugt
-----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.