From: dac.override@gmail.com (Dominick Grift)
Date: Wed, 14 Dec 2016 22:34:21 +0100
Subject: [refpolicy] [PATCH v2 1/5] wm: update the window manager (wm)
 module and enable its role template (v5)
In-Reply-To: <327faf4c-0676-abc3-fa8f-90f1b7b8a952@ieee.org>
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>
Message-ID: <ba8053cf-503f-d3d9-bb47-6ccf3bd1017b@gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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


> 
> 
>>  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/55f7efd5/attachment.bin