-----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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
