* Ok I am trying to build interfaces using X Controls. @ 2008-03-03 20:32 Daniel J Walsh 2008-03-03 21:39 ` Daniel J Walsh 0 siblings, 1 reply; 5+ messages in thread From: Daniel J Walsh @ 2008-03-03 20:32 UTC (permalink / raw) To: Eamon Walsh, SE Linux -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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; 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. Does any of this make sense? Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfMYGEACgkQrlYvE4MpobMNbwCgw/CfdKIrShUD3MTA7lZTO7gq 9kkAoN8Nbp4Y60ACF9/PkICxqWnzgKU9 =htFQ -----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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ok I am trying to build interfaces using X Controls. 2008-03-03 20:32 Ok I am trying to build interfaces using X Controls Daniel J Walsh @ 2008-03-03 21:39 ` Daniel J Walsh 2008-03-03 23:02 ` Eamon Walsh 0 siblings, 1 reply; 5+ messages in thread From: Daniel J Walsh @ 2008-03-03 21:39 UTC (permalink / raw) To: Eamon Walsh, SE Linux -----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. > > 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. > > Does any of this make sense? > > Dan > - -- 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 iEYEARECAAYFAkfMb/YACgkQrlYvE4MpobN5twCfTyFOeCXWd7leygMfHwSVuuy5 AGIAnRihufoJhKeFviQ94ETgEy9a3PtR =JRVb -----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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ok I am trying to build interfaces using X Controls. 2008-03-03 21:39 ` Daniel J Walsh @ 2008-03-03 23:02 ` Eamon Walsh 2008-03-04 13:51 ` Daniel J Walsh 0 siblings, 1 reply; 5+ messages in thread From: Eamon Walsh @ 2008-03-03 23:02 UTC (permalink / raw) To: Daniel J Walsh; +Cc: SE Linux, Christopher J. PeBenito 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. >> 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. -- 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ok I am trying to build interfaces using X Controls. 2008-03-03 23:02 ` Eamon Walsh @ 2008-03-04 13:51 ` Daniel J Walsh 2008-03-04 20:16 ` Eamon Walsh 0 siblings, 1 reply; 5+ messages in thread From: Daniel J Walsh @ 2008-03-04 13:51 UTC (permalink / raw) To: Eamon Walsh; +Cc: SE Linux, Christopher J. PeBenito -----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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ok I am trying to build interfaces using X Controls. 2008-03-04 13:51 ` Daniel J Walsh @ 2008-03-04 20:16 ` Eamon Walsh 0 siblings, 0 replies; 5+ messages in thread From: Eamon Walsh @ 2008-03-04 20:16 UTC (permalink / raw) To: Daniel J Walsh; +Cc: SE Linux, Christopher J. PeBenito Daniel J Walsh wrote: > -----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. > The two properties that hold the selinux contexts should be read-only to everyone since only the server sets them. Actually I'm going to deprecate these shortly in favor of the GetWindowContext X protocol request anyway. If you don't care about the others, just collapse them down to one type and transition them to staff_f in your policy. The stuff that is there now is an example of how you might separate window hint properties from globally writable properties like the cut buffers. For events, too, you could probably collapse them down to staff_t. Again, the stuff that is there now is an example of how to separate input events, property notify events, and other types of event. Other people doing stricter separation might need this functionality. > 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@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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-03-04 20:16 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-03-03 20:32 Ok I am trying to build interfaces using X Controls Daniel J Walsh 2008-03-03 21:39 ` Daniel J Walsh 2008-03-03 23:02 ` Eamon Walsh 2008-03-04 13:51 ` Daniel J Walsh 2008-03-04 20:16 ` Eamon Walsh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.