[refpolicy] [PATCH v2 0/2] More /run changes

[refpolicy] [PATCH v2 0/2] More /run changes

[Sven Vermeulen]

This set contains a few more /run changes:
- dhcpc creates /run/dhcpc (through scripts in the dhcpcd-hooks)
- dbus' init script creates /run/dbus
- mysql' init script creates /run/mysqld

It will be submitted separately: first the changes to the contrib modules,
followed by the changes to the core policy modules.

This is the part for the core modules

Changes since v1
----------------

- The init script for mysql also needs setattr rights on the run dirs

Sven Vermeulen (2):
  DHCP client's hooks create /run/dhcpc directory
  Allow init scripts to create /run/mysqld and /run/dbus

 policy/modules/system/init.te       |    7 ++++++-
 policy/modules/system/sysnetwork.te |    3 ++-
 2 files changed, 8 insertions(+), 2 deletions(-)

-- 
1.7.8.6

[refpolicy] [PATCH v2 1/2] DHCP client's hooks create /run/dhcpc directory

[Sven Vermeulen]

This directory contains the working files for updating network-related files
(like resolv.conf for name servers) before they are copied to the fixed
location. Although already in use previously, this location (/var/run/dhcpc or
/var/run/dhcpcd) was statically defined on the system.

With the introduction of /run and systems having /var/run -> /run, this is now a
dynamically created directory by dhcpc_t. Hence, the policy is enhanced allowing
dhcpc_t to manage dhcpc_var_run_t directories, and include a file transition for
directories created in the var_run_t location(s).

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 policy/modules/system/sysnetwork.te |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/policy/modules/system/sysnetwork.te b/policy/modules/system/sysnetwork.te
index 8aed9d0..f3f9d47 100644
--- a/policy/modules/system/sysnetwork.te
+++ b/policy/modules/system/sysnetwork.te
@@ -65,7 +65,8 @@ filetrans_pattern(dhcpc_t, dhcp_state_t, dhcpc_state_t, file)
 
 # create pid file
 manage_files_pattern(dhcpc_t, dhcpc_var_run_t, dhcpc_var_run_t)
-files_pid_filetrans(dhcpc_t, dhcpc_var_run_t, file)
+manage_dirs_pattern(dhcpc_t, dhcpc_var_run_t, dhcpc_var_run_t)
+files_pid_filetrans(dhcpc_t, dhcpc_var_run_t, { file dir })
 
 # Allow read/write to /etc/resolv.conf and /etc/ntp.conf. Note that any files
 # in /etc created by dhcpcd will be labelled net_conf_t.
-- 
1.7.8.6

[refpolicy] [PATCH v2 1/2] DHCP client's hooks create /run/dhcpc directory

[Christopher J. PeBenito]

On 07/31/12 13:46, Sven Vermeulen wrote:
> This directory contains the working files for updating network-related files
> (like resolv.conf for name servers) before they are copied to the fixed
> location. Although already in use previously, this location (/var/run/dhcpc or
> /var/run/dhcpcd) was statically defined on the system.
> 
> With the introduction of /run and systems having /var/run -> /run, this is now a
> dynamically created directory by dhcpc_t. Hence, the policy is enhanced allowing
> dhcpc_t to manage dhcpc_var_run_t directories, and include a file transition for
> directories created in the var_run_t location(s).
> 
> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>  policy/modules/system/sysnetwork.te |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/policy/modules/system/sysnetwork.te b/policy/modules/system/sysnetwork.te
> index 8aed9d0..f3f9d47 100644
> --- a/policy/modules/system/sysnetwork.te
> +++ b/policy/modules/system/sysnetwork.te
> @@ -65,7 +65,8 @@ filetrans_pattern(dhcpc_t, dhcp_state_t, dhcpc_state_t, file)
>  
>  # create pid file
>  manage_files_pattern(dhcpc_t, dhcpc_var_run_t, dhcpc_var_run_t)
> -files_pid_filetrans(dhcpc_t, dhcpc_var_run_t, file)
> +manage_dirs_pattern(dhcpc_t, dhcpc_var_run_t, dhcpc_var_run_t)

Does it actually delete dirs?  Wouldn't create_dirs_pattern() be sufficient?

> +files_pid_filetrans(dhcpc_t, dhcpc_var_run_t, { file dir })

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH v2 2/2] Allow init scripts to create /run/mysqld and /run/dbus

[Sven Vermeulen]

Allow the init scripts to create /run/mysqld and /run/dbus with the proper file
transition in place

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 policy/modules/system/init.te |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
index 6ae70ea..e389323 100644
--- a/policy/modules/system/init.te
+++ b/policy/modules/system/init.te
@@ -626,6 +626,8 @@ optional_policy(`
 
 optional_policy(`
 	dbus_connect_system_bus(initrc_t)
+	dbus_create_system_dbusd_run_dirs(initrc_t)
+	dbus_generic_pid_filetrans_system_dbusd_run(initrc_t, dir, "dbus")
 	dbus_system_bus_client(initrc_t)
 	dbus_read_config(initrc_t)
 
@@ -738,9 +740,12 @@ optional_policy(`
 		mysql_manage_db_dirs(initrc_t)
 	')
 
+	mysql_create_run_dirs(initrc_t)
+	mysql_generic_run_filetrans_pid(initrc_t, dir, "mysqld")
+	mysql_read_config(initrc_t)
+	mysql_setattr_run_dirs(initrc_t)
 	mysql_stream_connect(initrc_t)
 	mysql_write_log(initrc_t)
-	mysql_read_config(initrc_t)
 ')
 
 optional_policy(`
-- 
1.7.8.6

[refpolicy] [PATCH v2 2/2] Allow init scripts to create /run/mysqld and /run/dbus

[Christopher J. PeBenito]

On 07/31/12 13:46, Sven Vermeulen wrote:
> Allow the init scripts to create /run/mysqld and /run/dbus with the proper file
> transition in place
> 
> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>  policy/modules/system/init.te |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
> index 6ae70ea..e389323 100644
> --- a/policy/modules/system/init.te
> +++ b/policy/modules/system/init.te
> @@ -626,6 +626,8 @@ optional_policy(`
>  
>  optional_policy(`
>  	dbus_connect_system_bus(initrc_t)
> +	dbus_create_system_dbusd_run_dirs(initrc_t)
> +	dbus_generic_pid_filetrans_system_dbusd_run(initrc_t, dir, "dbus")
>  	dbus_system_bus_client(initrc_t)
>  	dbus_read_config(initrc_t)
>  
> @@ -738,9 +740,12 @@ optional_policy(`
>  		mysql_manage_db_dirs(initrc_t)
>  	')
>  
> +	mysql_create_run_dirs(initrc_t)
> +	mysql_generic_run_filetrans_pid(initrc_t, dir, "mysqld")
> +	mysql_read_config(initrc_t)
> +	mysql_setattr_run_dirs(initrc_t)
>  	mysql_stream_connect(initrc_t)
>  	mysql_write_log(initrc_t)
> -	mysql_read_config(initrc_t)

It seems that there would be a couple possibilities to think about.  The first would be to consider making init script domains for these services because their init scripts do so much.  The second would be to investigate the possibility of some set of interfaces (probably reverse) so that we don't have to update init with all of the /run directory creation rules.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH v2 2/2] Allow init scripts to create /run/mysqld and /run/dbus

[Sven Vermeulen]

On Tue, Aug 7, 2012 at 7:20 PM, Christopher J. PeBenito
<cpebenito@tresys.com> wrote:
> It seems that there would be a couple possibilities to think about.  The first would be to
> consider making init script domains for these services because their init scripts do so
> much.  The second would be to investigate the possibility of some set of interfaces
> (probably reverse) so that we don't have to update init with all of the /run directory
> creation rules.

I have been thinking (and playing) with the interface idea too.
However, it would go away from the current "domain-driven" interfaces
(where almost all interfaces' first argument is the domain on which it
has effect) which might seem awkward to use (and I haven't the
faintest idea how to call the interface then).

Something like "init_generic_run_init_create_run_dirs(mysqld_var_run_t,
"mysqld")" which allows initrc_t to create the "mysqld" directory in
var_run_t with an automatic type transition towards mysqld_var_run_t.

Another idea I had was to transform the run directories, like so:

"""
type mysqld_var_run_t;
files_pid_file(mysqld_var_run_t)
files_dynamic_run_dir(mysqld_var_run_t, "mysqld")
"""

This would then just have automatic file transitions for /run. period:

interface(`files_dynamic_run_dir',`
  gen_require(`
    type var_run_t;
  ')
  filetrans_pattern(domain, var_run_t, $1, dir, $2)
')

So if an init script, named init script, application domain or user
does something like "mkdir /run/mysqld" then it automatically becomes
mysqld_var_run_t.

[refpolicy] [PATCH v2 2/2] Allow init scripts to create /run/mysqld and /run/dbus

[Christopher J. PeBenito]

On 08/07/12 13:35, Sven Vermeulen wrote:
> On Tue, Aug 7, 2012 at 7:20 PM, Christopher J. PeBenito
> <cpebenito@tresys.com> wrote:
>> It seems that there would be a couple possibilities to think about.  The first would be to
>> consider making init script domains for these services because their init scripts do so
>> much.  The second would be to investigate the possibility of some set of interfaces
>> (probably reverse) so that we don't have to update init with all of the /run directory
>> creation rules.
> 
> I have been thinking (and playing) with the interface idea too.
> However, it would go away from the current "domain-driven" interfaces
> (where almost all interfaces' first argument is the domain on which it
> has effect) which might seem awkward to use (and I haven't the
> faintest idea how to call the interface then).
> 
> Something like "init_generic_run_init_create_run_dirs(mysqld_var_run_t,
> "mysqld")" which allows initrc_t to create the "mysqld" directory in
> var_run_t with an automatic type transition towards mysqld_var_run_t.
> 
> Another idea I had was to transform the run directories, like so:
> 
> """
> type mysqld_var_run_t;
> files_pid_file(mysqld_var_run_t)
> files_dynamic_run_dir(mysqld_var_run_t, "mysqld")
> """
> 
> This would then just have automatic file transitions for /run. period:
> 
> interface(`files_dynamic_run_dir',`
>   gen_require(`
>     type var_run_t;
>   ')
>   filetrans_pattern(domain, var_run_t, $1, dir, $2)
> ')
> 
> So if an init script, named init script, application domain or user
> does something like "mkdir /run/mysqld" then it automatically becomes
> mysqld_var_run_t.

Well I wouldn't go with the above because its way too broad, unnecessarily gives access to all domains, and breaks encapsulation.  But the idea might make more sense if we create a daemon pid file concept and allow initrc_t to create all daemon pid file dirs.  It would be similarly structured as your above examples.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH v2 2/2] Allow init scripts to create /run/mysqld and /run/dbus

[Sven Vermeulen]

On Tue, Aug 7, 2012 at 7:42 PM, Christopher J. PeBenito
<cpebenito@tresys.com> wrote:
>> So if an init script, named init script, application domain or user
>> does something like "mkdir /run/mysqld" then it automatically becomes
>> mysqld_var_run_t.
>
> Well I wouldn't go with the above because its way too broad, unnecessarily gives
> access to all domains, and breaks encapsulation.  But the idea might make more
> sense if we create a daemon pid file concept and allow initrc_t to create all daemon
> pid file dirs.  It would be similarly structured as your above examples.

I generally agree, but there are probably many "corner cases". I
mentioned one for DHCP before (which needs it instead of initrc_t),
another one is in the pipeline (tor, gentoo bug #429486). I imagine
there are quite a few others as well.

However, the "corner cases" don't have the downside of having three
different parties (initrc_t, var_run_t, <domain>_var_run_t) so can be
more easily updated:
files_pid_filetrans(tor_t, tor_var_run_t, dir, "tor") in tor.te
(assuming this is what the bug is about, haven't seen it in detail
yet).

I'll try with daemonpidfile and see how far we get.

Thanks for the feedback,
  Sven Vermeulen

[refpolicy] [PATCH v2 2/2] Allow init scripts to create /run/mysqld and /run/dbus

[Dominick Grift]

On Tue, 2012-08-07 at 19:59 +0200, Sven Vermeulen wrote:
> On Tue, Aug 7, 2012 at 7:42 PM, Christopher J. PeBenito
> <cpebenito@tresys.com> wrote:
> >> So if an init script, named init script, application domain or user
> >> does something like "mkdir /run/mysqld" then it automatically becomes
> >> mysqld_var_run_t.
> >
> > Well I wouldn't go with the above because its way too broad, unnecessarily gives
> > access to all domains, and breaks encapsulation.  But the idea might make more
> > sense if we create a daemon pid file concept and allow initrc_t to create all daemon
> > pid file dirs.  It would be similarly structured as your above examples.
> 
> I generally agree, but there are probably many "corner cases". I
> mentioned one for DHCP before (which needs it instead of initrc_t),
> another one is in the pipeline (tor, gentoo bug #429486). I imagine
> there are quite a few others as well.
> 
> However, the "corner cases" don't have the downside of having three
> different parties (initrc_t, var_run_t, <domain>_var_run_t) so can be
> more easily updated:
> files_pid_filetrans(tor_t, tor_var_run_t, dir, "tor") in tor.te
> (assuming this is what the bug is about, haven't seen it in detail
> yet).
> 
> I'll try with daemonpidfile and see how far we get.

About initrc_t creating all these objects on /run and other tmpfs.

I think we should make that conditional.

Reasons:

Not all systems use /run (older systems probably don't have run)
In systems with systemd, systemd-tmpfilesd takes care of creation of
this content.

Although the initrc_t domain is considered trusted anyways. So i am not
sure. Your input on this issue?

> Thanks for the feedback,
>   Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] [PATCH v2 2/2] Allow init scripts to create /run/mysqld and /run/dbus

[Christopher J. PeBenito]

On 08/07/12 14:04, Dominick Grift wrote:
> On Tue, 2012-08-07 at 19:59 +0200, Sven Vermeulen wrote:
>> On Tue, Aug 7, 2012 at 7:42 PM, Christopher J. PeBenito
>> <cpebenito@tresys.com> wrote:
>>>> So if an init script, named init script, application domain or user
>>>> does something like "mkdir /run/mysqld" then it automatically becomes
>>>> mysqld_var_run_t.
>>>
>>> Well I wouldn't go with the above because its way too broad, unnecessarily gives
>>> access to all domains, and breaks encapsulation.  But the idea might make more
>>> sense if we create a daemon pid file concept and allow initrc_t to create all daemon
>>> pid file dirs.  It would be similarly structured as your above examples.
>>
>> I generally agree, but there are probably many "corner cases". I
>> mentioned one for DHCP before (which needs it instead of initrc_t),
>> another one is in the pipeline (tor, gentoo bug #429486). I imagine
>> there are quite a few others as well.
>>
>> However, the "corner cases" don't have the downside of having three
>> different parties (initrc_t, var_run_t, <domain>_var_run_t) so can be
>> more easily updated:
>> files_pid_filetrans(tor_t, tor_var_run_t, dir, "tor") in tor.te
>> (assuming this is what the bug is about, haven't seen it in detail
>> yet).
>>
>> I'll try with daemonpidfile and see how far we get.
> 
> About initrc_t creating all these objects on /run and other tmpfs.
> 
> I think we should make that conditional.
> 
> Reasons:
> 
> Not all systems use /run (older systems probably don't have run)
> In systems with systemd, systemd-tmpfilesd takes care of creation of
> this content.
> 
> Although the initrc_t domain is considered trusted anyways. So i am not
> sure. Your input on this issue?

Its a valid point, but my current feeling is that its ok.  Just as you say, initrc_t is trusted.  If it is doing bad things, the system is in bad shape and extra directory creation perms in (/var)?/run is the least of your concerns.  If its a concern, we could always move to init script domains (eg httpd_initrc_t).  Thats a significant effort, but it would separate out a bunch of initrc_t's permissions.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH v2 2/2] Allow init scripts to create /run/mysqld and /run/dbus

[Sven Vermeulen]

On Tue, Aug 07, 2012 at 01:42:22PM -0400, Christopher J. PeBenito wrote:
> > """
> > type mysqld_var_run_t;
> > files_pid_file(mysqld_var_run_t)
> > files_dynamic_run_dir(mysqld_var_run_t, "mysqld")
> > """
> > 
> > This would then just have automatic file transitions for /run. period:
> > 
> > interface(`files_dynamic_run_dir',`
> >   gen_require(`
> >     type var_run_t;
> >   ')
> >   filetrans_pattern(domain, var_run_t, $1, dir, $2)
> > ')
> > 
> > So if an init script, named init script, application domain or user
> > does something like "mkdir /run/mysqld" then it automatically becomes
> > mysqld_var_run_t.
> 
> Well I wouldn't go with the above because its way too broad, unnecessarily 
> gives access to all domains, and breaks encapsulation.  But the idea might
> make more sense if we create a daemon pid file concept and allow initrc_t
> to create all daemon pid file dirs.  It would be similarly structured as
> your above examples.

So I've been thinking about this. Let's say we define an attribute called
"daemonrundir" (or "daemonpidfile" [1]) and provide a transformation
interface for that. In order to allow initrc_t to create these directories,
we need to assign the name of the directory to use simultaneously with it.

# $1 = rundir type, $2 = name of directory
interface(`files_daemon_run_dir',`
	gen_require(`
		attribute daemonrundir;
	')

	typeattribute $1 daemonrundir;

	init_generic_run_filetrans_specified_run_dir($1, $2)
')

Another interface would allow creating directories of types that have the
daemonrundir attribute set:

# $1 = domain allowed access
interface(`files_create_daemon_run_dir',`
	gen_require(`
		attribute daemonrundir;
	')

	create_dirs_pattern($1, daemonrundir, daemonrundir)
')

The final one is the "weird" one, for which I don't know a good naming
convention for:

# $1 = specified rundir type, $2 = name of the directory for which transition occurs
interface(`init_generic_run_filetrans_specified_run_dir',`
	gen_require(`
		type initrc_t;
	')

	files_pid_filetrans(initrc_t, $1, dir, $2)
')

Is this about what you had in mind (or could go for)?

It would mean we just need to do things like:

diff --git a/tor.te b/tor.te
index c842cad..6a0547a 100644
--- a/tor.te
+++ b/tor.te
@@ -35,6 +35,7 @@ logging_log_file(tor_var_log_t)
 # pid files
 type tor_var_run_t;
 files_pid_file(tor_var_run_t)
+files_daemon_run_dir(tor_var_run_t, "tor")
 

Another possibility would be to make it part of the files_pid_file()
transformation (with an optional second parameter) but I don't think we can
do stuff like the following, can we?

ifdef(`$2',`
  # some additional statements if $2 is present
')

Wkr,
	Sven Vermeulen


[1] I am considering using "run" instead of "pid" for most purposes since
    PID files are nowadays the minority of stuff that is labeled with
    *_var_run_t.

[refpolicy] [PATCH v2 2/2] Allow init scripts to create /run/mysqld and /run/dbus

[Christopher J. PeBenito]

On 08/10/12 13:28, Sven Vermeulen wrote:
> On Tue, Aug 07, 2012 at 01:42:22PM -0400, Christopher J. PeBenito wrote:
>>> """
>>> type mysqld_var_run_t;
>>> files_pid_file(mysqld_var_run_t)
>>> files_dynamic_run_dir(mysqld_var_run_t, "mysqld")
>>> """
>>>
>>> This would then just have automatic file transitions for /run. period:
>>>
>>> interface(`files_dynamic_run_dir',`
>>>   gen_require(`
>>>     type var_run_t;
>>>   ')
>>>   filetrans_pattern(domain, var_run_t, $1, dir, $2)
>>> ')
>>>
>>> So if an init script, named init script, application domain or user
>>> does something like "mkdir /run/mysqld" then it automatically becomes
>>> mysqld_var_run_t.
>>
>> Well I wouldn't go with the above because its way too broad, unnecessarily 
>> gives access to all domains, and breaks encapsulation.  But the idea might
>> make more sense if we create a daemon pid file concept and allow initrc_t
>> to create all daemon pid file dirs.  It would be similarly structured as
>> your above examples.
> 
> So I've been thinking about this. Let's say we define an attribute called
> "daemonrundir" (or "daemonpidfile" [1]) and provide a transformation
> interface for that. In order to allow initrc_t to create these directories,
> we need to assign the name of the directory to use simultaneously with it.
> 
> # $1 = rundir type, $2 = name of directory
> interface(`files_daemon_run_dir',`
> 	gen_require(`
> 		attribute daemonrundir;
> 	')
> 
> 	typeattribute $1 daemonrundir;
> 
> 	init_generic_run_filetrans_specified_run_dir($1, $2)
> ')
> 
> Another interface would allow creating directories of types that have the
> daemonrundir attribute set:
> 
> # $1 = domain allowed access
> interface(`files_create_daemon_run_dir',`
> 	gen_require(`
> 		attribute daemonrundir;
> 	')
> 
> 	create_dirs_pattern($1, daemonrundir, daemonrundir)
> ')
> 
> The final one is the "weird" one, for which I don't know a good naming
> convention for:
> 
> # $1 = specified rundir type, $2 = name of the directory for which transition occurs
> interface(`init_generic_run_filetrans_specified_run_dir',`
> 	gen_require(`
> 		type initrc_t;
> 	')
> 
> 	files_pid_filetrans(initrc_t, $1, dir, $2)
> ')
> 
> Is this about what you had in mind (or could go for)?

I had something like this in mind, except in my mind daemonpidfile was going to live in init module, so the implementation would be simpler.  The daemon concept already exists in init, so it makes sense to me.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com