From: dac.override@gmail.com (Dominick Grift)
Date: Wed, 14 Dec 2016 23:01:26 +0100
Subject: [refpolicy] [PATCH v2 1/5] wm: update the window manager (wm)
 module and enable its role template (v5)
In-Reply-To: <de57baa3-0dfc-1d41-ea1b-5a7d55607c2e@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>
	<CAPuKSJbhx+9kkU_KK5qX8s6ALknojqTeqmtjrkJR0fkVBn=wWg@mail.gmail.com>
	<1481726222.4419.9.camel@trentalancia.net>
	<1481729627.14900.7.camel@trentalancia.net>
	<327faf4c-0676-abc3-fa8f-90f1b7b8a952@ieee.org>
	<ba8053cf-503f-d3d9-bb47-6ccf3bd1017b@gmail.com>
	<5c4ca0ef-3ab6-ffb4-9a1c-a0a1402b0e5b@gmail.com>
	<de57baa3-0dfc-1d41-ea1b-5a7d55607c2e@gmail.com>
Message-ID: <8d0a5c07-7919-c66f-926d-0d3a9fd0f610@gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 12/14/2016 10:52 PM, Dominick Grift wrote:
> 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" <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 <guido@trentalancia.net>
>>>>>>> ---
>>>>>>>  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]
>>>>>
>>>>> ########################################
>>>>> ## <summary>
>>>>> ##	Create a domain for applications
>>>>> ##	that are launched by the window
>>>>> ##	manager.
>>>>> ## </summary>
>>>>> ## <desc>
>>>>> ##	<p>
>>>>> ##	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.
>>>>> ##	</p>
>>>>> ##	<p>
>>>>> ##	The types will be made usable as a domain and file, making
>>>>> ##	calls to domain_type() and files_type() redundant.
>>>>> ##	</p>
>>>>> ## </desc>
>>>>> ## <param name="target_domain">
>>>>> ##	<summary>
>>>>> ##	Type to be used in the domain transition as the application
>>>>> ##	domain.
>>>>> ##	</summary>
>>>>> ## </param>
>>>>> ## <param name="entry_point">
>>>>> ##	<summary>
>>>>> ##	Type of the program to be used as an entry point to this domain.
>>>>> ##	</summary>
>>>>> ## </param>
>>>>> ## <param name="source_domain">
>>>>> ##	<summary>
>>>>> ##	Type to be used as the source window manager domain.
>>>>> ##	</summary>
>>>>> ## </param>
>>>>> ## <infoflow type="none"/>
>>>>> #
>>>>> 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
> 

Both of out solutions have their pros and cons. Not suggesting refpolicy
uses my solution. Just giving a glimpse what you potentially can expect
down the road.

>>>
>>>>
>>>>
>>>>>  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/1ff48a60/attachment-0001.bin