This is a larger set of structured changes to the system
utilities. The main drivers are supporting the new /run location,
but some smaller changes have been incorporated as well.
Changes since v1
----------------
- Use var_lock_t in the gen_require of files_pid_filetrans_lock_dir
Sven Vermeulen (6):
Support log location for init script logging
Allow init scripts to handle sysctls
Supporting interfaces for the /run changes
Allow init scripts to populate /run location
Prepare udev interfaces for /run usage
Allow init scripts to create and manage (udev) /run location
policy/modules/kernel/files.if | 61 +++++++++++++++++++++++++++++++++
policy/modules/system/init.te | 15 +++++++-
policy/modules/system/udev.if | 74 +++++++++++++++++++++++++++++++++++++++-
3 files changed, 148 insertions(+), 2 deletions(-)
--
1.7.3.4
Recent init script packages allow for logging init script progress (service
start/stop state information, sometimes even duration, etc.) so we introduce an
initrc_var_log_t logtype and allow initrc_t to manage this.
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/system/init.te | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
index 5fb9683..9fdd704 100644
--- a/policy/modules/system/init.te
+++ b/policy/modules/system/init.te
@@ -74,6 +74,9 @@ files_type(initrc_state_t)
type initrc_tmp_t;
files_tmp_file(initrc_tmp_t)
+type initrc_var_log_t;
+logging_log_file(initrc_var_log_t)
+
type initrc_var_run_t;
files_pid_file(initrc_var_run_t)
@@ -255,6 +258,9 @@ manage_dirs_pattern(initrc_t, initrc_tmp_t, initrc_tmp_t)
manage_lnk_files_pattern(initrc_t, initrc_tmp_t, initrc_tmp_t)
files_tmp_filetrans(initrc_t, initrc_tmp_t, { file dir })
+manage_dirs_pattern(initrc_t, initrc_var_log_t, initrc_var_log_t)
+logging_log_filetrans(initrc_t, initrc_var_log_t, dir)
+
init_write_initctl(initrc_t)
kernel_read_system_state(initrc_t)
--
1.7.3.4
The init script(s) that set/reset the sysctl's require the sys_admin capability
(as you cannot change sysctls without it).
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/system/init.te | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
index 9fdd704..7dfd9a9 100644
--- a/policy/modules/system/init.te
+++ b/policy/modules/system/init.te
@@ -222,7 +222,7 @@ optional_policy(`
#
allow initrc_t self:process { getpgid setsched setpgid setrlimit getsched };
-allow initrc_t self:capability ~{ sys_admin sys_module };
+allow initrc_t self:capability ~{ sys_module };
dontaudit initrc_t self:capability sys_module; # sysctl is triggering this
allow initrc_t self:passwd rootok;
allow initrc_t self:key manage_key_perms;
--
1.7.3.4
Since most distributions now support /run (which, thanks the the
file context substitutions, is marked as var_run_t), we need to update the
SELinux policies to support "dynamically" building up /run. Unlike /var/run,
which is most likely statically defined during distribution installation, /run
is a tmpfs which is built up from scratch on each and every boot.
But not only that, many services also use this location for other purposes than
just PID files (which is to be expected as these "other reasons" is why /run
came to be in the first place), so we need to support other types within this
location easily.
For this reason, we introduce support to
- creating the /run/lock location
- supporting named file transitions when init scripts create stuff in /run
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/kernel/files.if | 61 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/policy/modules/kernel/files.if b/policy/modules/kernel/files.if
index 41346fb..e951402 100644
--- a/policy/modules/kernel/files.if
+++ b/policy/modules/kernel/files.if
@@ -5608,6 +5608,26 @@ interface(`files_list_locks',`
########################################
## <summary>
+## Create lock directories
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access
+## </summary>
+## </param>
+#
+interface(`files_create_lock_dirs',`
+ gen_require(`
+ type var_t, var_lock_t;
+ ')
+
+ allow $1 var_t:dir search_dir_perms;
+ allow $1 var_lock_t:lnk_file read_lnk_file_perms;
+ create_dirs_pattern($1, var_lock_t, var_lock_t)
+')
+
+########################################
+## <summary>
## Add and remove entries in the /var/lock
## directories.
## </summary>
@@ -5628,6 +5648,24 @@ interface(`files_rw_lock_dirs',`
########################################
## <summary>
+## Set the attributes of the generic lock directories.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`files_setattr_lock_dirs',`
+ gen_require(`
+ type var_t, var_lock_t;
+ ')
+
+ setattr_dirs_pattern($1, var_t, var_lock_t)
+')
+
+########################################
+## <summary>
## Relabel to and from all lock directory types.
## </summary>
## <param name="domain">
@@ -6016,6 +6054,29 @@ interface(`files_pid_filetrans',`
########################################
## <summary>
+## Create a generic lock directory within the run directories
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access
+## </summary>
+## </param>
+## <param name="name" optional="true">
+## <summary>
+## The name of the object being created.
+## </summary>
+## </param>
+#
+interface(`files_pid_filetrans_lock_dir',`
+ gen_require(`
+ type var_lock_t;
+ ')
+
+ files_pid_filetrans($1, var_lock_t, dir, $2)
+')
+
+########################################
+## <summary>
## Read and write generic process ID files.
## </summary>
## <param name="domain">
--
1.7.3.4
At boot up, the /run location is empty, and init scripts are responsible for
creating the necessary structure within to support their services. This means,
adding entries like for the lock folder (/run/lock).
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/system/init.te | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
index 7dfd9a9..8667e14 100644
--- a/policy/modules/system/init.te
+++ b/policy/modules/system/init.te
@@ -275,7 +275,10 @@ kernel_rw_all_sysctls(initrc_t)
# for lsof which is used by alsa shutdown:
kernel_dontaudit_getattr_message_if(initrc_t)
+files_create_lock_dirs(initrc_t)
+files_pid_filetrans_lock_dir(initrc_t, "lock")
files_read_kernel_symbol_table(initrc_t)
+files_setattr_lock_dirs(initrc_t)
corecmd_exec_all_executables(initrc_t)
@@ -451,6 +454,7 @@ ifdef(`distro_gentoo',`
# allow bootmisc to create /var/lock/.keep.
files_manage_generic_locks(initrc_t)
+ files_pid_filetrans(initrc_t, initrc_state_t, dir, "openrc")
# openrc uses tmpfs for its state data
fs_tmpfs_filetrans(initrc_t, initrc_state_t, { dir file fifo_file lnk_file })
--
1.7.3.4
Recent udev implementations now use /run (actually, /run/udev) for storing
database files, rules and more. Hence, we need to extend existing interfaces to
support searching through the udev_var_run_t location (as most of that was
previously only in device_t and/or etc_t or udev_etc_t)
Next to enhancing the interfaces, we provide additional ones that will be used
by the init script (for udev) which needs to create and support the new
/run/udev locations.
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/system/udev.if | 74 ++++++++++++++++++++++++++++++++++++++++-
1 files changed, 73 insertions(+), 1 deletions(-)
diff --git a/policy/modules/system/udev.if b/policy/modules/system/udev.if
index 025348a..f1d1ce0 100644
--- a/policy/modules/system/udev.if
+++ b/policy/modules/system/udev.if
@@ -146,6 +146,10 @@ interface(`udev_manage_rules_files',`
')
manage_files_pattern($1, udev_rules_t, udev_rules_t)
+
+ files_search_etc($1)
+
+ udev_search_pids($1)
')
########################################
@@ -187,10 +191,16 @@ interface(`udev_read_db',`
type udev_tbl_t;
')
- dev_list_all_dev_nodes($1)
allow $1 udev_tbl_t:dir list_dir_perms;
+
read_files_pattern($1, udev_tbl_t, udev_tbl_t)
read_lnk_files_pattern($1, udev_tbl_t, udev_tbl_t)
+
+ dev_list_all_dev_nodes($1)
+
+ files_search_etc($1)
+
+ udev_search_pids($1)
')
########################################
@@ -214,6 +224,68 @@ interface(`udev_rw_db',`
########################################
## <summary>
+## Search through udev pid content
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`udev_search_pids',`
+ gen_require(`
+ type udev_var_run_t;
+ ')
+
+ files_search_pids($1)
+ search_dirs_pattern($1, udev_var_run_t, udev_var_run_t)
+')
+
+########################################
+## <summary>
+## Create directories in the run location with udev_var_run_t type
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+## <param name="name" optional="true">
+## <summary>
+## Name of the directory that is created
+## </summary>
+## </param>
+#
+interface(`udev_pid_filetrans_run_dirs',`
+ gen_require(`
+ type udev_var_run_t;
+ ')
+
+ files_pid_filetrans($1, udev_var_run_t, dir, $2)
+')
+
+########################################
+## <summary>
+## Create, read, write, and delete
+## udev pid directories
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`udev_manage_pid_dirs',`
+ gen_require(`
+ type udev_var_run_t;
+ ')
+
+ files_search_var($1)
+ manage_dirs_pattern($1, udev_var_run_t, udev_var_run_t)
+')
+
+########################################
+## <summary>
## Create, read, write, and delete
## udev pid files.
## </summary>
--
1.7.3.4
With udev now using /run for its data, the init script responsible for preparing
the environment to start up udev needs to be able to setup this location as
well.
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/system/init.te | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
index 8667e14..c544eea 100644
--- a/policy/modules/system/init.te
+++ b/policy/modules/system/init.te
@@ -276,6 +276,7 @@ kernel_rw_all_sysctls(initrc_t)
kernel_dontaudit_getattr_message_if(initrc_t)
files_create_lock_dirs(initrc_t)
+files_create_pid_dirs(initrc_t)
files_pid_filetrans_lock_dir(initrc_t, "lock")
files_read_kernel_symbol_table(initrc_t)
files_setattr_lock_dirs(initrc_t)
@@ -828,7 +829,9 @@ optional_policy(`
optional_policy(`
udev_rw_db(initrc_t)
+ udev_pid_filetrans_run_dirs(initrc_t, "udev")
udev_manage_pid_files(initrc_t)
+ udev_manage_pid_dirs(initrc_t)
udev_manage_rules_files(initrc_t)
')
--
1.7.3.4
On 06/28/12 15:17, Sven Vermeulen wrote:
> Recent init script packages allow for logging init script progress (service
> start/stop state information, sometimes even duration, etc.) so we introduce an
> initrc_var_log_t logtype and allow initrc_t to manage this.
>
> Signed-off-by: Sven Vermeulen <[email protected]>
> ---
> policy/modules/system/init.te | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
> index 5fb9683..9fdd704 100644
> --- a/policy/modules/system/init.te
> +++ b/policy/modules/system/init.te
> @@ -74,6 +74,9 @@ files_type(initrc_state_t)
> type initrc_tmp_t;
> files_tmp_file(initrc_tmp_t)
>
> +type initrc_var_log_t;
> +logging_log_file(initrc_var_log_t)
> +
> type initrc_var_run_t;
> files_pid_file(initrc_var_run_t)
>
> @@ -255,6 +258,9 @@ manage_dirs_pattern(initrc_t, initrc_tmp_t, initrc_tmp_t)
> manage_lnk_files_pattern(initrc_t, initrc_tmp_t, initrc_tmp_t)
> files_tmp_filetrans(initrc_t, initrc_tmp_t, { file dir })
>
> +manage_dirs_pattern(initrc_t, initrc_var_log_t, initrc_var_log_t)
> +logging_log_filetrans(initrc_t, initrc_var_log_t, dir)
> +
> init_write_initctl(initrc_t)
>
> kernel_read_system_state(initrc_t)
Oops, I missed you had a v2. Same thing I said for v1, no file access.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 06/28/12 15:17, Sven Vermeulen wrote:
> The init script(s) that set/reset the sysctl's require the sys_admin capability
> (as you cannot change sysctls without it).
>
> Signed-off-by: Sven Vermeulen <[email protected]>
> ---
> policy/modules/system/init.te | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
> index 9fdd704..7dfd9a9 100644
> --- a/policy/modules/system/init.te
> +++ b/policy/modules/system/init.te
> @@ -222,7 +222,7 @@ optional_policy(`
> #
>
> allow initrc_t self:process { getpgid setsched setpgid setrlimit getsched };
> -allow initrc_t self:capability ~{ sys_admin sys_module };
> +allow initrc_t self:capability ~{ sys_module };
> dontaudit initrc_t self:capability sys_module; # sysctl is triggering this
> allow initrc_t self:passwd rootok;
> allow initrc_t self:key manage_key_perms;
We typically try to separate out the sys_admin privileges since its so broad. Can a new domain be created?
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Mon, Jul 02, 2012 at 10:47:43AM -0400, Christopher J. PeBenito wrote:
> > allow initrc_t self:process { getpgid setsched setpgid setrlimit getsched };
> > -allow initrc_t self:capability ~{ sys_admin sys_module };
> > +allow initrc_t self:capability ~{ sys_module };
> > dontaudit initrc_t self:capability sys_module; # sysctl is triggering this
> > allow initrc_t self:passwd rootok;
> > allow initrc_t self:key manage_key_perms;
>
> We typically try to separate out the sys_admin privileges since its so broad. Can a new domain be created?
Its the init script calling the sysctl binary. We currently don't hold a
separate domain for sysctl, but that's certainly doable. I guess it would
start with allowing both initrc_t and sysadm_t to transition to sysctl_t.
But for some reason I think this has been thought of before - sysctl's are
well known throughout the policy (with specific labels for kernel sysctl's
and such). Was a new domain for sysctl's not done because there was little
need for, or am I missing something?
Wkr,
Sven Vermeulen
On Mon, 2012-07-02 at 22:19 +0200, Sven Vermeulen wrote:
> On Mon, Jul 02, 2012 at 10:47:43AM -0400, Christopher J. PeBenito wrote:
> > > allow initrc_t self:process { getpgid setsched setpgid setrlimit getsched };
> > > -allow initrc_t self:capability ~{ sys_admin sys_module };
> > > +allow initrc_t self:capability ~{ sys_module };
> > > dontaudit initrc_t self:capability sys_module; # sysctl is triggering this
> > > allow initrc_t self:passwd rootok;
> > > allow initrc_t self:key manage_key_perms;
> >
> > We typically try to separate out the sys_admin privileges since its so broad. Can a new domain be created?
>
> Its the init script calling the sysctl binary. We currently don't hold a
> separate domain for sysctl, but that's certainly doable. I guess it would
> start with allowing both initrc_t and sysadm_t to transition to sysctl_t.
>
> But for some reason I think this has been thought of before - sysctl's are
> well known throughout the policy (with specific labels for kernel sysctl's
> and such). Was a new domain for sysctl's not done because there was little
> need for, or am I missing something?
or create a init_script_domain() for this particular script maybe?
> Wkr,
> Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
On 7/2/2012 4:19 PM, Sven Vermeulen wrote:
> On Mon, Jul 02, 2012 at 10:47:43AM -0400, Christopher J. PeBenito wrote:
>>> allow initrc_t self:process { getpgid setsched setpgid setrlimit getsched };
>>> -allow initrc_t self:capability ~{ sys_admin sys_module };
>>> +allow initrc_t self:capability ~{ sys_module };
>>> dontaudit initrc_t self:capability sys_module; # sysctl is triggering this
>>> allow initrc_t self:passwd rootok;
>>> allow initrc_t self:key manage_key_perms;
>>
>> We typically try to separate out the sys_admin privileges since its so broad. Can a new domain be created?
>
> Its the init script calling the sysctl binary. We currently don't hold a
> separate domain for sysctl, but that's certainly doable. I guess it would
> start with allowing both initrc_t and sysadm_t to transition to sysctl_t.
>
> But for some reason I think this has been thought of before - sysctl's are
> well known throughout the policy (with specific labels for kernel sysctl's
> and such). Was a new domain for sysctl's not done because there was little
> need for, or am I missing something?
My guess is that its a new capability check, or its a capability check for a sysctl that isn't often set.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Tue, Jul 03, 2012 at 09:59:52AM -0400, Christopher J. PeBenito wrote:
> > Its the init script calling the sysctl binary. We currently don't hold a
> > separate domain for sysctl, but that's certainly doable. I guess it would
> > start with allowing both initrc_t and sysadm_t to transition to sysctl_t.
> >
> > But for some reason I think this has been thought of before - sysctl's are
> > well known throughout the policy (with specific labels for kernel sysctl's
> > and such). Was a new domain for sysctl's not done because there was little
> > need for, or am I missing something?
>
> My guess is that its a new capability check, or its a capability check for a sysctl that isn't often set.
Yes, there are apparently a few cases in sysctls where this is hit. In my
particular case, it is on grSecurity sysctl's. There's something in the
kernel about "tainted" sysctls as well which also require the CAP_SYS_ADMIN
capability before writing to them.
That said, I removed that particular part from the patchset as I've still
got a few questions on this case. I was first going to create a sysctl_t
domain... but that one already exists, although it isn't a domain (yet) but
rather the label given to sysctl's in /proc/sys.
I don't think it is wise to make sysctl_t a domain as well, do you? If not,
is it still a good idea to move sysctl in its own domain and would I then
need to rename sysctl_t (the current one) to something else, or look for a
other name for the domain?
Another way to handle this is to make a sysctl_initrc_t domain (like
Dominick suggested) but that'll be more different for Gentoo to take as we
currently don't use such named init scripts yet (but I have to start
supporting that anyhow sometime, so this is as good a time as any I guess).
Wkr,
Sven Vermeulen
On 07/03/12 13:49, Sven Vermeulen wrote:
> On Tue, Jul 03, 2012 at 09:59:52AM -0400, Christopher J. PeBenito wrote:
>>> Its the init script calling the sysctl binary. We currently don't hold a
>>> separate domain for sysctl, but that's certainly doable. I guess it would
>>> start with allowing both initrc_t and sysadm_t to transition to sysctl_t.
>>>
>>> But for some reason I think this has been thought of before - sysctl's are
>>> well known throughout the policy (with specific labels for kernel sysctl's
>>> and such). Was a new domain for sysctl's not done because there was little
>>> need for, or am I missing something?
>>
>> My guess is that its a new capability check, or its a capability check for a sysctl that isn't often set.
>
> Yes, there are apparently a few cases in sysctls where this is hit. In my
> particular case, it is on grSecurity sysctl's. There's something in the
> kernel about "tainted" sysctls as well which also require the CAP_SYS_ADMIN
> capability before writing to them.
>
> That said, I removed that particular part from the patchset as I've still
> got a few questions on this case. I was first going to create a sysctl_t
> domain... but that one already exists, although it isn't a domain (yet) but
> rather the label given to sysctl's in /proc/sys.
>
> I don't think it is wise to make sysctl_t a domain as well, do you? If not,
> is it still a good idea to move sysctl in its own domain and would I then
> need to rename sysctl_t (the current one) to something else, or look for a
> other name for the domain?
It would be better to find another name for the domain, otherwise we'd have compatibility problems. e.g. someone has a custom policy module installed that has a domain that sets sysctls.
> Another way to handle this is to make a sysctl_initrc_t domain (like
> Dominick suggested) but that'll be more different for Gentoo to take as we
> currently don't use such named init scripts yet (but I have to start
> supporting that anyhow sometime, so this is as good a time as any I guess).
I don't have a strong feeling either way.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com