2011-03-10 07:32:50

by harrytaurus2002

[permalink] [raw]
Subject: [refpolicy] Why mcstrans daemon needs to run at mls_systemhigh?


Hello,

In current setrans.te implementation the setrans_t would run at mls_systemhigh if MLS is enabled. Why is this necessary?

The unix_stream_socket object that bond to the socket file of "/var/run/setrans/.setrans-unix" would have mls_systemhigh as well, rendering that application domains at mls_systemlow unable to connect to it. We will have below error message such as:

type=AVC msg=audit(1299571674.264:342): avc: denied { connectto } for pid=1687 comm="secon" path="/var/run/setrans/.setrans-unix" scontext=root:sysadm_r:sysadm_t:s0-s15:c0.c1023 tcontext=system_u:system_r:setrans_t:s15:c0.c1023 tclass=unix_stream_socket

type=AVC msg=audit(1299571690.332:361): avc: denied { connectto } for pid=1697 comm="newrole" path="/var/run/setrans/.setrans-unix" scontext=root:sysadm_r:newrole_t:s0-s15:c0.c1023 tcontext=system_u:system_r:setrans_t:s15:c0.c1023 tclass=unix_stream_socket

In oder to allow date to flow from mls_systemlow to mls_systemhigh, we would have to add the latter as MLS trusted object, for example, mls_trusted_object(setrans_t) (Alternatively we could add application domains to mlsnetwritetoclr attribute, but the number of such application domains could be many). Why indeed is this needed? I mean if mcstrans daemon runs at mls_systemlow then we won't have the problem from the beginning.

Ideas?

Thanks a lot!

Best regards,
Harry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110310/cf011801/attachment.html


2011-03-12 12:29:20

by harrytaurus2002

[permalink] [raw]
Subject: [refpolicy] FW: Why mcstrans daemon needs to run at mls_systemhigh?


Oops, I have not received below email sent to oss.tresys.com 2 days ago, so try to re-send to oss1.tresys.com.

Thanks,
Harry



From: [email protected]
To: refpolicy at oss.tresys.com
Subject: Why mcstrans daemon needs to run at mls_systemhigh?
Date: Thu, 10 Mar 2011 07:32:50 +0000




Hello,

In current setrans.te implementation the setrans_t would run at mls_systemhigh if MLS is enabled. Why is this necessary?

The unix_stream_socket object that bond to the socket file of "/var/run/setrans/.setrans-unix" would have mls_systemhigh as well, rendering that application domains at mls_systemlow unable to connect to it. We will have below error message such as:

type=AVC msg=audit(1299571674.264:342): avc: denied { connectto } for pid=1687 comm="secon" path="/var/run/setrans/.setrans-unix" scontext=root:sysadm_r:sysadm_t:s0-s15:c0.c1023 tcontext=system_u:system_r:setrans_t:s15:c0.c1023 tclass=unix_stream_socket

type=AVC msg=audit(1299571690.332:361): avc: denied { connectto } for pid=1697 comm="newrole" path="/var/run/setrans/.setrans-unix" scontext=root:sysadm_r:newrole_t:s0-s15:c0.c1023 tcontext=system_u:system_r:setrans_t:s15:c0.c1023 tclass=unix_stream_socket

In oder to allow date to flow from mls_systemlow to mls_systemhigh, we would have to add the latter as MLS trusted object, for example, mls_trusted_object(setrans_t) (Alternatively we could add application domains to mlsnetwritetoclr attribute, but the number of such application domains could be many). Why indeed is this needed? I mean if mcstrans daemon runs at mls_systemlow then we won't have the problem from the beginning.

Ideas?

Thanks a lot!

Best regards,
Harry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110312/ad93d358/attachment.html

2011-03-14 12:30:25

by cpebenito

[permalink] [raw]
Subject: [refpolicy] Why mcstrans daemon needs to run at mls_systemhigh?

On 3/10/2011 2:32 AM, HarryCiao wrote:
> Hello,
>
> In current setrans.te implementation the setrans_t would run at
> mls_systemhigh if MLS is enabled. Why is this necessary?

Because label translations have sensitivities. For example, the
translation for s15:c5 could be sensitive. So, for setrans to have all
of the translations, it has to be system high.

> The unix_stream_socket object that bond to the socket file of
> "/var/run/setrans/.setrans-unix" would have mls_systemhigh as well,
> rendering that application domains at mls_systemlow unable to connect to
> it. We will have below error message such as:
>
> type=AVC msg=audit(1299571674.264:342): avc: denied { connectto } for
> pid=1687 comm="secon" path="/var/run/setrans/.setrans-unix"
> scontext=root:sysadm_r:sysadm_t:s0-s15:c0.c1023
> tcontext=system_u:system_r:setrans_t:s15:c0.c1023 tclass=unix_stream_socket
>
> type=AVC msg=audit(1299571690.332:361): avc: denied { connectto } for
> pid=1697 comm="newrole" path="/var/run/setrans/.setrans-unix"
> scontext=root:sysadm_r:newrole_t:s0-s15:c0.c1023
> tcontext=system_u:system_r:setrans_t:s15:c0.c1023 tclass=unix_stream_socket
>
> In oder to allow date to flow f rom mls_systemlow to mls_systemhigh, we
> would have to add the latter as MLS trusted object, for example,
> mls_trusted_object(setrans_t) (Alternatively we could add application
> domains to mlsnetwritetoclr attribute, but the number of such
> application domains could be many). Why indeed is this needed? I mean if
> mcstrans daemon runs at mls_systemlow then we won't have the problem
> from the beginning.

--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com