Allow kern_unconfined domains to use syslog capability
PATCH 1/1 Allow kern_unconfined domains to use syslog capability
When an unconfined_t root user runs dmesg, the kernel complains with this message in its logs (when SELinux is in enforcing mode):
dmesg (16289): Attempt to access syslog with CAP_SYS_ADMIN but no CAP_SYSLOG (deprecated).
audit.log contains following AVC:
avc: denied { syslog } for pid=16289 comm="dmesg" capability=34 scontext=unconfined_u:unconfined_r:unconfined_t tcontext=unconfined_u:unconfined_r:unconfined_t tclass=capability2
Moreover, policy/modules/kernel/kernel.if defineskernel_read_ring_buffer interface as:
allow $1 self:capability2 syslog;
allow $1 kernel_t:system syslog_read;
As domains with kern_unconfined attribute already have all kernel_t:system permissions, this patch allows such domains to use CAP_SYSLOG.
--- policy/modules/kernel/kernel.te | 1 + 1 file changed, 1 insertion(+)
policy/modules/kernel/kernel.te +1 -0
@@ -417,6 +417,7 @@ allow kern_unconfined proc_type:{ dir file lnk_file } *; allow kern_unconfined sysctl_type:{ dir file } *; +allow kern_unconfined self:capability2 syslog; allow kern_unconfined kernel_t:system *; allow kern_unconfined unlabeled_t:dir_file_class_set *;
Signature · 1 line
1.9.2
PATCH 1/1 Allow kern_unconfined domains to use syslog capability
Quoted 30 lines · Nicolas Iooss
When an
unconfined_troot user runs dmesg, the kernel complains with this message in its logs (when SELinux is in enforcing mode):dmesg (16289): Attempt to access syslog with
CAP_SYS_ADMINbut noCAP_SYSLOG(deprecated).audit.log contains following AVC:
avc: denied { syslog } for pid=16289 comm="dmesg" capability=34 scontext=unconfined_u:unconfined_r:unconfined_t tcontext=unconfined_u:unconfined_r:unconfined_t tclass=capability2
Moreover, policy/modules/kernel/kernel.if defines
kernel_read_ring_bufferinterface as:allow $1 self:capability2 syslog;
allow $1 kernel_t:systemsyslog_read;As domains with
kern_unconfinedattribute already have all kernel_t:system permissions, this patch allows such domains to useCAP_SYSLOG.--- policy/modules/kernel/kernel.te | 1 + 1 file changed, 1 insertion(+)policy/modules/kernel/kernel.te +0
-0
policy/modules/kernel/kernel.te allow kern_unconfined proc_type:{ dir file lnk_file } *; · line 423
Quoted 7 lines
policy/modules/kernel/kernel.te +1
-0@@ -417,6 +417,7 @@ allow kern_unconfined proc_type:{ dir file lnk_file } *; allow kern_unconfined sysctl_type:{ dir file } *; +allow kern_unconfined self:capability2 syslog; allow kern_unconfined kernel_t:system *; allow kern_unconfined unlabeled_t:dir_file_class_set *;
Unconfined_t's capabilities are currently managed in unconfined.if. That's where this should be fixed.
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH 1/1 Allow kern_unconfined domains to use syslog capability
2014-05-27 15:07 GMT+02:00 Christopher J. PeBenito:
Quoted 4 lines · Nicolas Iooss
Unconfined_t's capabilities are currently managed in unconfined.if. That's where this should be fixed.
This is actually not so true. Here is the current situation about unconfined_t capabilities:
* unconfined.te contains:
allow unconfined_t self:capability2 block_suspend;
unconfined_domain(unconfined_t)* unconfined_domain interface is defined in unconfined.if and contains:
allow $1 self:capability ~sys_module;
I don't understand why the "capability" policy of unconfined_t is managed in unconfined.if and its "capability2" one in unconfined.te. I would expect both to be either in unconfined.if or in unconfined.te, but at the same time I don't know what can break if the current situation is modified.
Back to my patch, where should I put the syslog capability2 permission? In unconfined.te with block_suspend or in unconfined.if?
--
Nicolas
PATCH 1/1 Allow kern_unconfined domains to use syslog capability
2014-05-29 0:24 GMT+02:00 Nicolas Iooss <[email protected]>:
Quoted 9 lines
2014-05-27 15:07 GMT+02:00 Christopher J. PeBenito:
Quoted 4 lines · Nicolas Iooss
Unconfined_t's capabilities are currently managed in unconfined.if. That's where this should be fixed.
This is actually not so true. Here is the current situation about
unconfined_tcapabilities:
Quoted 8 lines
* unconfined.te contains:
allow unconfined_t self:capability2 block_suspend; unconfined_domain(unconfined_t)*
unconfined_domaininterface is defined in unconfined.if and contains:allow $1 self:capability ~sys_module;
Oops, in fact I've been reading a custom patched policy where unconfined_t also has block_suspend capability. Refpolicy only has things in unconfined.if. Sorry for the noise. I'll send a patch for unconfined.if as soon as I've taken enough time to test it.
Nicolas