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 defines
kernel_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(+)
diff --git a/policy/modules/kernel/kernel.te b/policy/modules/kernel/kernel.te
index c7cd4e4..f436490 100644
--- a/policy/modules/kernel/kernel.te
+++ b/policy/modules/kernel/kernel.te
@@ -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 *;
--
1.9.2
On 05/23/2014 12:22 PM, Nicolas Iooss wrote:
> 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 defines
> kernel_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(+)
>
> diff --git a/policy/modules/kernel/kernel.te b/policy/modules/kernel/kernel.te
> index c7cd4e4..f436490 100644
> --- a/policy/modules/kernel/kernel.te
> +++ b/policy/modules/kernel/kernel.te
> @@ -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.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
2014-05-27 15:07 GMT+02:00 Christopher J. PeBenito:
> On 05/23/2014 12:22 PM, Nicolas Iooss wrote:
>
> 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
2014-05-29 0:24 GMT+02:00 Nicolas Iooss <[email protected]>:
>
> 2014-05-27 15:07 GMT+02:00 Christopher J. PeBenito:
> > On 05/23/2014 12:22 PM, Nicolas Iooss wrote:
> >
> > 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;
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