-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eamon Walsh wrote: > Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Daniel J Walsh wrote: >>> What are these doing? Why do I need these? >>> >>> type_transition $2_t default_xproperty_t:x_property >>> $2_default_xproperty_t; >>> >>> type_transition $2_t property_xevent_t:x_event $2_property_xevent_t; >>> type_transition $2_t focus_xevent_t:x_event $2_focus_xevent_t; >>> type_transition $2_t manage_xevent_t:x_event $2_manage_xevent_t; >>> type_transition $2_t default_xevent_t:x_event $2_default_xevent_t; >>> >> Looking at this further, I think these should be classes. >> >> allow staff_t self:property_xevent_t send; >> >> Have all xevent with the same class is similar to having blk_file, >> chr_file, sock_file all class file and defining transitions. >> > > This makes sense, and it's something I considered, however I couldn't > get the set of classes nailed down firmly enough to make a decision. The > class structure was too rigid, in my opinion, to support this kind of > categorization. > > It's even worse with window properties, which are based on an open-ended > namespace. All kinds of zany conventions have been established > regarding the use of this or that property, and who knows what other > ones might come along. > > But are any of these worth anything from a security perspective? Are we adding huge complexity for any reason. Is xevent enough or x_property in most cases. If I can set one x_property will I need to set them all. I hate type explosions, because it just generates AVC errors and unexpected errors. I think we should think of the interactions we are trying to stop and then only generate the types necessary to prevent these interactions. If all we want to stop is cut/paste screencapture keyboard sniffing focus grab ... Lets build up the limited types to control this interaction. Another way to look at it would be the way we have labeled /proc. We only add a new type when there is a justifiable security difference. > >>> I want to refer to all of the XClass via the main type. >>> >>> Lets take an example. >>> >>> I write policy for all X Apps that staff_t runs without a transition to >>> stay staff_t. >>> >>> Now I write a transition rule for staff_mozilla_t. >>> >>> So I want to say something like >>> >>> xserver_paste_pattern(staff_mozilla_t, staff_t) >>> >>> I would like to then write something like >>> >>> allow staff_mozilla_t staff_t:x_property read; >>> >>> But you make me write. >>> >>> allow staff_mozilla_t staff_default_x_property_t:x_property read; >>> >>> Which screws up the interface and I end up having to pass around staff >>> and staff_mozilla. >>> >>> Is this necessary? >>> >>> Is this legal? >>> type_transition $2_t input_xevent_t:x_event $2_t; >>> >>> Or is it even necessary? >>> >>> I really want to build an interface that says >>> >>> xserver_application(staff, staff_t) >>> >>> xserver_application(staff, staff_mozilla_t) >>> >>> Then define any interactions between staff_t and staff_mozilla_t via >>> simple interfaces. > > If you're already passing (staff, staff_t) around then why not just pass > the prefixes to your interaction function? > > xserver_interact(staff, staff_t, staff_mozilla, staff_mozilla_t) > > doesn't look that bad to me. > > It's not my fault that we have all these complex constructions just to > make sure everything has a "_t" on the end of it. > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfNU9oACgkQrlYvE4MpobPAuQCdHLMeuE+kSpfNyNYQ+jzjsyO5 UUoAn2Pxu030f6iGOCgTc79DY0NFwVm3 =j+HT -----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.
