[refpolicy] [PATCH v2 1/5] wm: update the window manager (wm) module and enable its role template (v5)

[pebenito@ieee.org (Chris PeBenito)]

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.


>  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.




-- 
Chris PeBenito