From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from facesaver.epoch.ncsc.mil (facesaver [144.51.25.10]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m23M54Zx031059 for ; Mon, 3 Mar 2008 17:05:04 -0500 Message-ID: <47CC75E2.2020300@tycho.nsa.gov> Date: Mon, 03 Mar 2008 17:04:18 -0500 From: Eamon Walsh MIME-Version: 1.0 To: Daniel J Walsh CC: SELinux List Subject: Re: Tonights rawhide contains a fix to stop xspy. References: <47C63353.9040008@redhat.com> <47C6650F.2060909@tycho.nsa.gov> <47C6C16D.1010002@redhat.com> <47C7857C.7070406@tycho.nsa.gov> <47C80DFF.4080307@redhat.com> In-Reply-To: <47C80DFF.4080307@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Daniel J Walsh wrote: > -----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? Not without putting apps into separate domains. > Can I prevent all nsplugin_t from putting up a login screen? You can prevent nsplugin_t from creating child windows of the root window (as opposed to child windows of the firefox window). > Can I > prevent it from writing anywhere but to a window owned by firefox_t? Yes, by denying permissions on other types of windows. > > 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? Apps in the same domain can listen to keyboard events from each other's windows, fullstop. -- Eamon Walsh 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.