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

[dac.override@gmail.com (Dominick Grift)]

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

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