From: dac.override@gmail.com (Dominick Grift) Date: Wed, 14 Dec 2016 22:52:10 +0100 Subject: [refpolicy] [PATCH v2 1/5] wm: update the window manager (wm) module and enable its role template (v5) In-Reply-To: <5c4ca0ef-3ab6-ffb4-9a1c-a0a1402b0e5b@gmail.com> References: <1481130053.3300.9.camel@trentalancia.net> <1481217618.20182.8.camel@trentalancia.net> <1481322107.2989.1.camel@trentalancia.net> <1481676520.17446.9.camel@trentalancia.net> <1481680495.3551.1.camel@trentalancia.net> <1481726222.4419.9.camel@trentalancia.net> <1481729627.14900.7.camel@trentalancia.net> <327faf4c-0676-abc3-fa8f-90f1b7b8a952@ieee.org> <5c4ca0ef-3ab6-ffb4-9a1c-a0a1402b0e5b@gmail.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 12/14/2016 10:45 PM, Dominick Grift wrote: > On 12/14/2016 10:34 PM, Dominick Grift wrote: >> On 12/14/2016 10:23 PM, Chris PeBenito via refpolicy wrote: >>> On 12/14/16 10:33, Guido Trentalancia via refpolicy wrote: >>>> Hello again. >>>> >>>> I am back with a possible solution to the problem that you described... >>>> >>>> On Wed, 14/12/2016 at 15.37 +0100, Guido Trentalancia via refpolicy >>>> wrote: >>>>> On Wed, 14/12/2016 at 21.01 +0800, Jason Zaman wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 14 Dec 2016 09:54, "Guido Trentalancia via refpolicy" >>>>> @o >>>>>> ss.tresys.com> wrote: >>>>>> Enable the window manager role (wm contrib module) and update >>>>>> the module to work with gnome-shell. >>>>>> >>>>>> This patch requires the following recently posted patch for the >>>>>> games module: >>>>>> >>>>>> [PATCH v3 1/2] games: general update and improved pulseaudio >>>>>> integration >>>>>> http://oss.tresys.com/pipermail/refpolicy/2016-December/008679.html >>>>>> >>>>>> This patch has received some testing with the following two >>>>>> configurations: >>>>>> - gnome-shell executing in normal mode (with display managers >>>>>> other than gdm, such as xdm from XOrg); >>>>>> - gnome-shell executing in gdm mode (with the Gnome Display >>>>>> Manager). >>>>>> >>>>>> Patches 3/5, 4/5 and 5/5 are needed when gnome-shell is used >>>>>> in conjunction with gdm. >>>>>> >>>>>> Since the window managers are not limited by gnome-shell, this >>>>>> latter >>>>>> version of the patch (along with part 2/5) uses separate optional >>>>>> conditionals for the gnome and wm role templates. >>>>>> >>>>>> Signed-off-by: Guido Trentalancia >>>>>> --- >>>>>> policy/modules/contrib/colord.te | 5 ++ >>>>>> policy/modules/contrib/dbus.te | 5 ++ >>>>>> policy/modules/contrib/wm.if | 43 +++++++++++++++++- >>>>>> policy/modules/contrib/wm.te | 88 >>>>>> ++++++++++++++++++++++++++++++++++++- >>>>>> policy/modules/roles/staff.te | 8 ++- >>>>>> policy/modules/roles/sysadm.te | 4 + >>>>>> policy/modules/roles/unprivuser.te | 8 ++- >>>>>> 7 files changed, 155 insertions(+), 6 deletions(-) >>>>> >>>>> [...] >>>>> >>>>>> >>>>>> @@ -55,10 +96,51 @@ optional_policy(` >>>>>> ') >>>>>> >>>>>> optional_policy(` >>>>>> + consolekit_dbus_chat(wm_domain) >>>>>> +') >>>>>> + >>>>>> +optional_policy(` >>>>>> devicekit_dbus_chat_power(wm_domain) >>>>>> ') >>>>>> >>>>>> optional_policy(` >>>>>> + evolution_domtrans(wm_domain) >>>>>> + >>>>>> + optional_policy(` >>>>>> + evolution_dbus_chat(wm_domain) >>>>>> + evolution_alarm_dbus_chat(wm_domain) >>>>>> + ') >>>>>> +') >>>>>> + >>>>>> +optional_policy(` >>>>>> + games_domtrans(wm_domain) >>>>>> + >>>>>> + optional_policy(` >>>>>> + games_dbus_chat(wm_domain) >>>>>> + ') >>>>>> +') >>>>>> + >>>>>> +optional_policy(` >>>>>> + java_domtrans(wm_domain) >>>>>> +') >>>>>> + >>>>>> +optional_policy(` >>>>>> + mono_domtrans(wm_domain) >>>>>> +') >>>>>> + >>>>>> +optional_policy(` >>>>>> + mozilla_domtrans(wm_domain) >>>>>> + >>>>>> + optional_policy(` >>>>>> + mozilla_dbus_chat(wm_domain) >>>>>> + ') >>>>>> +') >>>>>> + >>>>>> +optional_policy(` >>>>>> + mplayer_domtrans(wm_domain) >>>>>> +') >>>>>> + >>>>>> +optional_policy(` >>>>>> networkmanager_dbus_chat(wm_domain) >>>>>> ') >>>>>> >>>>>> Whoa are we going to have to add every single application to >>>>>> wm_domain to be able to run it? That will get annoying super fast. >>>>>> Isn't there an application_domain attribute we can use? If there >>>>>> isn't we might want to reverse this so X application types instead >>>>>> declare that wm can run them (something like the application_type >>>>>> interface) >>>>> >>>>> I am now trying to get back to you on this, provided that I >>>>> understood >>>>> the meaning of what you proposed... >>>>> >>>>> I suppose you are suggesting to use an interface such as >>>>> wm_application() in the module of each application that needs to be >>>>> run >>>>> by the window manager and avoid calling applicationname_domtrans() >>>>> from >>>>> the wm module. >>>>> >>>>> Even if that was possible, there would be a loss of visibility in the >>>>> wm module about what applications it can actually run. >>>>> >>>>> The latter is undesirable in my opinion and defeats the purpose of >>>>> having a separate wm module to control what the window manager can >>>>> and >>>>> cannot do, because at that point it would be each application module >>>>> which decides if the application can run or not in the window >>>>> manager. >>>> >>>> It is possible to achieve what you are seeking. You just need to use >>>> the following interface (in policy/modules/contrib/wm.if): >>>> >>>> [cut] >>>> >>>> ######################################## >>>> ## >>>> ## Create a domain for applications >>>> ## that are launched by the window >>>> ## manager. >>>> ## >>>> ## >>>> ##

>>>> ## Create a domain for applications that are launched by the >>>> ## window manager (implying a domain transition). Typically >>>> ## these are graphical applications that are run interactively. >>>> ##

>>>> ##

>>>> ## The types will be made usable as a domain and file, making >>>> ## calls to domain_type() and files_type() redundant. >>>> ##

>>>> ##
>>>> ## >>>> ## >>>> ## Type to be used in the domain transition as the application >>>> ## domain. >>>> ## >>>> ## >>>> ## >>>> ## >>>> ## Type of the program to be used as an entry point to this domain. >>>> ## >>>> ## >>>> ## >>>> ## >>>> ## Type to be used as the source window manager domain. >>>> ## >>>> ## >>>> ## >>>> # >>>> interface(`wm_application_domain',` >>>> gen_require(` >>>> attribute wm_domain; >>>> ') >>>> >>>> application_type($1) >>>> ubac_constrained($1) >>>> application_executable_file($2) >>>> domtrans_pattern(wm_domain, $2, $1) >>>> ') >>>> >>>> [cut] >>>> >>>> and then, for each application that you want to enable from the window >>>> manager, you need to call the interface wm_application_domain() from >>>> the application module similarly to the way the >>>> userdom_user_application_domain() interface is currently called. >>>> >>>> For example, for mozilla: >>>> >>>> [cut] >>>> >>>> --- refpolicy-git-orig/policy/modules/contrib/mozilla.te 2016-12-09 22:29:53.579462880 +0100 >>>> +++ refpolicy-git/policy/modules/contrib/mozilla.te 2016-12-14 16:28:46.055294184 +0100 >>>> @@ -22,6 +39,7 @@ type mozilla_exec_t; >>>> typealias mozilla_t alias { user_mozilla_t staff_mozilla_t sysadm_mozilla_t }; >>>> typealias mozilla_t alias { auditadm_mozilla_t secadm_mozilla_t }; >>>> userdom_user_application_domain(mozilla_t, mozilla_exec_t) >>>> +wm_application_domain(mozilla_t, mozilla_exec_t) >>> >>> I'd tend to prefer it this way, as long as you make this call optional. >> >> In the bigger picture this solution is a bit unwieldy in my view. There >> are various components that need to be able to run programs on behalf of >> the user. In this case it is gnome shell, but for example systemd --user >> needs the same, and there are various other instances. >> >> The solution i have in dssp is not perfect either. But for domain >> transitions that apply to more than the just shell i >> use a type attribute. >> >> example: mozilla_run(staff_type_attribute, role_attribute) >> >> Then i associate the type attribute also with the programs that need to >> be able to run the programs on behalf of the user. >> >> staff_type(staff_wm_t) >> staff_type(staff_systemd_t) >> >> It is not perfect either but atleast it provides a single point of >> failure. domain transitions apply automatically to all domains that need >> to be able to run programs on behalf of the user >> > > Some other examples: "torsocks firefox", "systemd-inhibit firefox". > > So lets say to have 10 user apps. Then you would have to update > (atleast) these four domains to allow them to run them with the same > domtrans as well. It gets ugly rather quick and hard to maintain > But in reference policy this does not work well. due to the "_role()" templates. The role templates also provides access to content, and we do not want to allow for example staff_wm_t, staff_systemd_t, staff_inhibit_t, staff_torsocks_t access to mozilla_home_t, mozilla_tmp_t etc etc >> >>> >>> >>>> role mozilla_roles types mozilla_t; >>>> >>>> type mozilla_home_t; >>>> >>>> [cut] >>>> >>>> I hope this helps. >>>> >>>> If the majority of people prefer that the policy changes in this >>>> direction, despite the side-effects that I have highlighted earlier on, >>>> I can amend the initial patch. >>> >>> >>> >>> >> >> > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161214/96a587b9/attachment.bin