On 3/7/19 10:01 PM, Sugar, David wrote:
On 3/7/19 6:55 PM, Chris PeBenito wrote:
On 3/6/19 2:07 PM, Sugar, David wrote:
Altered to use roleattribute based on suggestion
Signed-off-by: Dave Sugar <dsugar@xxxxxxxxxx>
---
policy/modules/system/udev.if | 26 ++++++++++++++++++++++++++
policy/modules/system/udev.te | 2 ++
2 files changed, 28 insertions(+)
diff --git a/policy/modules/system/udev.if
b/policy/modules/system/udev.if
index fee55852..90dfb17d 100644
--- a/policy/modules/system/udev.if
+++ b/policy/modules/system/udev.if
@@ -36,6 +36,32 @@ interface(`udev_domtrans',`
domtrans_pattern($1, udev_exec_t, udev_t)
')
+########################################
+## <summary>
+## Execute udev in the udev domain, and
+## allow the specified role the udev domain.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed to transition.
+## </summary>
+## </param>
+## <param name="role">
+## <summary>
+## Role allowed access.
+## </summary>
+## </param>
+## <rolecap/>
+#
+interface(`udev_run',`
+ gen_require(`
+ attribute_role udev_roles;
+ ')
+
+ udev_domtrans($1)
+ roleattribute $2 udev_roles;
+')
Why is a user be starting this?
In this case it isn't a user starting udev, rather calling
"/usr/bin/udevadm info" to gather all the specific information about a
USB device. udevadm is labeled udev_exec_t.
In that case I'd be more interested in seeing what it would take for a
separate udevadm domain. If that proves to be too much like udev_t,
then I'd accept the above patch.
--
Chris PeBenito
