Hello,
On Debian, several initscripts are creating both files (often pidfiles)
and directories under /var/run.
Currently there is the init_daemon_run_dir() interface that allows to
transition directories in the correct context. Dominick has suggested me
on IRC create a new interface to generalize to transition files
(something like init_pid_initrc_spec_filetrans()).
Does anybody have comments about this? About the name?
Cheers
Laurent Bigonville
On Thu, 2012-11-29 at 18:03 +0100, Laurent Bigonville wrote:
> Hello,
>
> On Debian, several initscripts are creating both files (often pidfiles)
> and directories under /var/run.
>
> Currently there is the init_daemon_run_dir() interface that allows to
> transition directories in the correct context. Dominick has suggested me
> on IRC create a new interface to generalize to transition files
> (something like init_pid_initrc_spec_filetrans()).
>
> Does anybody have comments about this? About the name?
>
> Cheers
Something like this is ugly and a compromize but it might work:
> From ec5d520859d207dde4ce5932b721a4dd7e9d6934 Thu, 29 Nov 2012 18:19:43 +0100
> From: Dominick Grift <[email protected]>
> Date: Thu, 29 Nov 2012 18:18:36 +0100
> Subject: [PATCH] test
>
>
> Signed-off-by: Dominick Grift <[email protected]>
> diff --git a/policy/modules/system/init.if b/policy/modules/system/init.if
> index 3f0c2d3..e78edf1 100644
> --- a/policy/modules/system/init.if
> +++ b/policy/modules/system/init.if
> @@ -417,29 +417,33 @@
>
> ########################################
> ## <summary>
> -## Mark the file type as a daemon run dir, allowing initrc_t
> -## to create it
> +## Allow specified objects with specified
> +## file types to be created by init
> +## scripts with a type transition.
> ## </summary>
> -## <param name="filetype">
> +## <param name="private_type">
> ## <summary>
> -## Type to mark as a daemon run dir
> +## Private file type.
> ## </summary>
> ## </param>
> -## <param name="filename">
> +## <param name="object_class">
> ## <summary>
> -## Filename of the directory that the init script creates
> +## Class of the object being created.
> +## </summary>
> +## </param>
> +## <param name="name" optional="true">
> +## <summary>
> +## The name of the object being created.
> ## </summary>
> ## </param>
> #
> -interface(`init_daemon_run_dir',`
> +interface(`init_script_spec_run_content',`
> gen_require(`
> - attribute daemonrundir;
> type initrc_t;
> ')
>
> - typeattribute $1 daemonrundir;
> -
> - files_pid_filetrans(initrc_t, $1, dir, $2)
> + allow initrc_t $1:$2 { create open getattr setattr read write append rename link unlink ioctl lock };
> + files_pid_filetrans(initrc_t, $1, $2, $3)
> ')
>
> ########################################
> diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
> index 5f2a36a..5114154 100644
> --- a/policy/modules/system/init.te
> +++ b/policy/modules/system/init.te
> @@ -29,9 +29,6 @@
> # Mark process types as daemons
> attribute daemon;
>
> -# Mark file type as a daemon run directory
> -attribute daemonrundir;
> -
> #
> # init_t is the domain of the init process.
> #
> @@ -244,9 +241,6 @@
> init_telinit(initrc_t)
>
> can_exec(initrc_t, init_script_file_type)
> -
> -create_dirs_pattern(initrc_t, daemonrundir, daemonrundir)
> -setattr_dirs_pattern(initrc_t, daemonrundir, daemonrundir)
>
> domtrans_pattern(init_run_all_scripts_domain, initrc_exec_t, initrc_t)
>
> diff --git a/policy/modules/system/udev.te b/policy/modules/system/udev.te
> index a2a4167..00bf416 100644
> --- a/policy/modules/system/udev.te
> +++ b/policy/modules/system/udev.te
> @@ -25,7 +25,7 @@
>
> type udev_var_run_t;
> files_pid_file(udev_var_run_t)
> -init_daemon_run_dir(udev_var_run_t, "udev")
> +init_script_spec_run_content(udev_var_run_t, { lnk_file dir }, "udev")
>
> ifdef(`enable_mcs',`
> kernel_ranged_domtrans_to(udev_t, udev_exec_t, s0 - mcs_systemhigh)
> Laurent Bigonville
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
On Thu, Nov 29, 2012 at 06:03:21PM +0100, Laurent Bigonville wrote:
> Currently there is the init_daemon_run_dir() interface that allows to
> transition directories in the correct context. Dominick has suggested me
> on IRC create a new interface to generalize to transition files
> (something like init_pid_initrc_spec_filetrans()).
Why not add in an init_daemon_run_file() interface?
It's perhaps a very personal opinion, but I find it easier to read:
type mysqld_var_run_t;
files_pid_file(mysqld_var_run_t)
init_daemon_run_dir(mysqld_var_run_t, "mysqld")
versus
type mysqld_var_run_t;
files_pid_file(mysqld_var_run_t)
init_pid_initrc_spec_filetrans(mysqld_var_run_t, dir, "mysqld")
The _spec_ always throws me off, as spec_domtrans_pattern is to imply that
the domain itself is SELinux-aware and will specify a transition itself. For
a spec_filetrans, I would expect the same behavior (i.e. no automatic file
transition, but the domain itself is SELinux-aware and choses a new file
type) - only it doesn't make sense, since for file transitions, no
policy-wise rules are needed (just allow the domain write to the parent type
and create for the target type + relabel rights?)
Wkr,
Sven Vermeulen
On Thu, 2012-11-29 at 18:49 +0100, Sven Vermeulen wrote:
> On Thu, Nov 29, 2012 at 06:03:21PM +0100, Laurent Bigonville wrote:
> > Currently there is the init_daemon_run_dir() interface that allows to
> > transition directories in the correct context. Dominick has suggested me
> > on IRC create a new interface to generalize to transition files
> > (something like init_pid_initrc_spec_filetrans()).
>
> Why not add in an init_daemon_run_file() interface?
I agree, that might indeed be a more elegant solution
> It's perhaps a very personal opinion, but I find it easier to read:
>
> type mysqld_var_run_t;
> files_pid_file(mysqld_var_run_t)
> init_daemon_run_dir(mysqld_var_run_t, "mysqld")
>
> versus
>
> type mysqld_var_run_t;
> files_pid_file(mysqld_var_run_t)
> init_pid_initrc_spec_filetrans(mysqld_var_run_t, dir, "mysqld")
I guess so yes. The spec also confuses me but i just look at it as
"specified" and do not really place that into any context.
> The _spec_ always throws me off, as spec_domtrans_pattern is to imply that
> the domain itself is SELinux-aware and will specify a transition itself. For
> a spec_filetrans, I would expect the same behavior (i.e. no automatic file
> transition, but the domain itself is SELinux-aware and choses a new file
> type) - only it doesn't make sense, since for file transitions, no
> policy-wise rules are needed (just allow the domain write to the parent type
> and create for the target type + relabel rights?)
>
> Wkr,
> Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy