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 <[email protected]>
> ---
> ?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.
Guido
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 <[email protected]>
> > ---
> > ?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)
?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.
Regards,
Guido
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 <[email protected]>
>>> ---
>>> 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
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 <[email protected]>
>>>> ---
>>>> 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
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 <[email protected]>
>>>>> ---
>>>>> 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
>
>>
>>
>>> 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/546e13f3/attachment-0001.bin
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 <[email protected]>
>>>>>> ---
>>>>>> 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
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 <[email protected]>
>>>>>>> ---
>>>>>>> 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
On 12/14/16 16:52, Dominick Grift via refpolicy 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:
[...]
>>>>> 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
The Fedora policy has had this concept for a long time and I never liked
it. It makes it much less obvious what a domain can do by looking at
the policy sources. It's easy to overlook the staff_type() call you
have above, and even if you see it, it may be hard to understand what
that truly implies.
I still feel that is the case, but it may be time to do it anyway. If
so, it would have to be only in a limited way, for example only for
domain transitions.
--
Chris PeBenito
On 12/14/2016 11:07 PM, Chris PeBenito wrote:
> On 12/14/16 16:52, Dominick Grift via refpolicy 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:
>
> [...]
>
>>>>>> 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
>
> The Fedora policy has had this concept for a long time and I never liked
> it. It makes it much less obvious what a domain can do by looking at
> the policy sources. It's easy to overlook the staff_type() call you
> have above, and even if you see it, it may be hard to understand what
> that truly implies.
>
I agree. It needs to be used with great care and it is certainly not a
perfect solution either.
> I still feel that is the case, but it may be time to do it anyway. If
> so, it would have to be only in a limited way, for example only for
> domain transitions.
>
In DSSP1 i use run interfaces. this is a bit more than strictly needed
because all the domains that need to run stuff on behalf of users can
then also read state and send signals, but i think its a reasonable
trade off.
The most compelling argument for this solution is the single point of
failure argument. Down the road with many programs this might really
make things more manage-able.
The argument to not do it is that one really needs to be careful that
one doesnt use this attribute for anything else, and that you'll lose
some flexibility.
>
--
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/1ec33cae/attachment.bin
I think that this should be avoided!
The policy needs to be easy to read and understand, otherwise its purpose would be defeated.
Guido
On the 14th December 2016 23:07:27 CET, Chris PeBenito via refpolicy <[email protected]> wrote:
>On 12/14/16 16:52, Dominick Grift via refpolicy 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:
>
>[...]
>
>>>>>> 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
>
>The Fedora policy has had this concept for a long time and I never
>liked
>it. It makes it much less obvious what a domain can do by looking at
>the policy sources. It's easy to overlook the staff_type() call you
>have above, and even if you see it, it may be hard to understand what
>that truly implies.
>
>I still feel that is the case, but it may be time to do it anyway. If
>so, it would have to be only in a limited way, for example only for
>domain transitions.
On 12/14/2016 11:14 PM, Guido Trentalancia via refpolicy wrote:
> I think that this should be avoided!
>
> The policy needs to be easy to read and understand, otherwise its purpose would be defeated.
>
Yes but in confined complex desktop environments there are complex
requirements. Maintaining these things separately will have its
drawbacks as well in the longer run.
Whatever you decide, its fine by me. I am just trying to give you a
glimpse of what you may expect as you go down the rabbit hole.
> On the 14th December 2016 23:07:27 CET, Chris PeBenito via refpolicy <[email protected]> wrote:
>> On 12/14/16 16:52, Dominick Grift via refpolicy 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:
>>
>> [...]
>>
>>>>>>> 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
>>
>> The Fedora policy has had this concept for a long time and I never
>> liked
>> it. It makes it much less obvious what a domain can do by looking at
>> the policy sources. It's easy to overlook the staff_type() call you
>> have above, and even if you see it, it may be hard to understand what
>> that truly implies.
>>
>> I still feel that is the case, but it may be time to do it anyway. If
>> so, it would have to be only in a limited way, for example only for
>> domain transitions.
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
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/b78f39ca/attachment.bin