Haveged is a simple daemon that feeds the systems' random pool entropy using
the HAVEGE algorithm.
The following posts contain the .te, .if, .fc as well as the sysadm role
enhancement to be able to manage the haveged process.
My suggestion is to stick this in the services/ category. Yet, if there is a
consensus that we don't want all services (especially relatively simple
ones) in the reference policy, then that is fine by me as well.
Wkr,
Sven Vermeulen
This is the general .te for the haveged_t domain. Beyond some basic logging
functionalities and access to the kernels' random devices, this deamon has
no additional requirements (as of yet).
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/services/haveged.te | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
create mode 100644 policy/modules/services/haveged.te
diff --git a/policy/modules/services/haveged.te b/policy/modules/services/haveged.te
new file mode 100644
index 0000000..7a5f92e
--- /dev/null
+++ b/policy/modules/services/haveged.te
@@ -0,0 +1,35 @@
+policy_module(haveged, 1.0.0)
+
+########################################
+#
+# Declarations
+#
+
+type haveged_t;
+type haveged_exec_t;
+init_daemon_domain(haveged_t, haveged_exec_t)
+
+type haveged_var_run_t;
+files_pid_file(haveged_var_run_t)
+
+########################################
+#
+# haveged local policy
+#
+allow haveged_t self:capability sys_admin;
+allow haveged_t self:unix_dgram_socket create_socket_perms;
+allow haveged_t haveged_var_run_t:file manage_file_perms;
+
+# pid file
+files_pid_filetrans(haveged_t, haveged_var_run_t, file)
+
+## Kernel stuff
+kernel_rw_kernel_sysctl(haveged_t)
+dev_read_rand(haveged_t)
+dev_write_rand(haveged_t)
+
+## System stuff
+miscfiles_read_localization(haveged_t)
+
+## Other stuff
+logging_send_syslog_msg(haveged_t)
--
1.7.3.4
Define the administrative interface so that domains can manage the haveged
processes.
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/services/haveged.if | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 policy/modules/services/haveged.if
diff --git a/policy/modules/services/haveged.if b/policy/modules/services/haveged.if
new file mode 100644
index 0000000..4bb8f4f
--- /dev/null
+++ b/policy/modules/services/haveged.if
@@ -0,0 +1,26 @@
+## <summary>Haveged service</summary>
+
+########################################
+## <summary>
+## Administer haveged
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+## <param name="role">
+## <summary>
+## The role to be allowed to manage the haveged domain.
+## </summary>
+## </param>
+## <rolecap/>
+#
+interface(`haveged_admin',`
+ gen_require(`
+ type haveged_t;
+ ')
+
+ allow $1 haveged_t:process { ptrace signal_perms };
+ ps_process_pattern($1, haveged_t)
+')
--
1.7.3.4
Assign the haveged binary the haveged_exec_t label.
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/services/haveged.fc | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 policy/modules/services/haveged.fc
diff --git a/policy/modules/services/haveged.fc b/policy/modules/services/haveged.fc
new file mode 100644
index 0000000..9fca26a
--- /dev/null
+++ b/policy/modules/services/haveged.fc
@@ -0,0 +1 @@
+/usr/sbin/haveged -- gen_context(system_u:object_r:haveged_exec_t,s0)
--
1.7.3.4
On 07/20/11 11:17, Sven Vermeulen wrote:
> Haveged is a simple daemon that feeds the systems' random pool entropy using
> the HAVEGE algorithm.
>
> The following posts contain the .te, .if, .fc as well as the sysadm role
> enhancement to be able to manage the haveged process.
>
> My suggestion is to stick this in the services/ category. Yet, if there is a
> consensus that we don't want all services (especially relatively simple
> ones) in the reference policy, then that is fine by me as well.
How about turning audioentropy into entropyd and putting both services
into the same domain? The former has more permissions, but not many of
consequence. We could make a tunable that makes the obvious audio stuff
configurable.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Wed, Jul 20, 2011 at 11:33:07AM -0400, Christopher J. PeBenito wrote:
> How about turning audioentropy into entropyd and putting both services
> into the same domain? The former has more permissions, but not many of
> consequence. We could make a tunable that makes the obvious audio stuff
> configurable.
Sounds like a plan ;-) I'll see to pull up some patches.
Wkr,
Sven Vermeulen