From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 27 Nov 2012 10:12:35 -0500
Subject: [refpolicy] [PATCH] Implement mcsuntrustedproc.
In-Reply-To: <50B3DDE5.7090506@redhat.com>
References: <1351881968-8686-1-git-send-email-dominick.grift@gmail.com>
	<50B3931F.906@tresys.com> <50B3DDE5.7090506@redhat.com>
Message-ID: <50B4D863.9000705@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 11/26/12 16:23, Daniel J Walsh wrote:
> On 11/26/2012 11:04 AM, Christopher J. PeBenito wrote:
>> On 11/02/12 14:46, Dominick Grift wrote:
>>>
>>> This process is not allowed to interact with subjects or operate on
>>> objects that it would otherwise be able to interact with or operate on 
>>> respectively.
>>>
>>> This is, i think, to make sure that specified processes cannot interact 
>>> with subject or operate on objects regardless of its mcs range.
>>>
>>> It is used by svirt and probably also by sandbox
>>>
>>> Signed-off-by: Dominick Grift <dominick.grift@gmail.com> diff --git
>>> a/policy/mcs b/policy/mcs index f477c7f..c366f56 100644 --- a/policy/mcs 
>>> +++ b/policy/mcs @@ -69,16 +69,32 @@ #  - /proc/pid operations are not
>>> constrained.
>>>
>>> mlsconstrain file { read ioctl lock execute execute_no_trans } -	(( h1
>>> dom h2 ) or ( t1 == mcsreadall ) or ( t2 == domain )); +	(( h1 dom h2 )
>>> or ( t1 == mcsreadall ) or +	(( t1 != mcsuntrustedproc ) and (t2 ==
>>> domain)));
>>>
>>> mlsconstrain file { write setattr append unlink link rename } -	(( h1 dom
>>> h2 ) or ( t1 == mcswriteall ) or ( t2 == domain )); +	(( h1 dom h2 ) or (
>>> t1 == mcswriteall ) or +	(( t1 != mcsuntrustedproc ) and (t2 ==
>>> domain)));
>>>
>>> mlsconstrain dir { search read ioctl lock } -	(( h1 dom h2 ) or ( t1 ==
>>> mcsreadall ) or ( t2 == domain )); +	(( h1 dom h2 ) or ( t1 == mcsreadall
>>> ) or +	(( t1 != mcsuntrustedproc ) and (t2 == domain)));
>>>
>>> mlsconstrain dir { write setattr append unlink link rename add_name
>>> remove_name } -	(( h1 dom h2 ) or ( t1 == mcswriteall ) or ( t2 == domain
>>> )); +	(( h1 dom h2 ) or ( t1 == mcswriteall ) or +	(( t1 !=
>>> mcsuntrustedproc ) and (t2 == domain))); + +mlsconstrain fifo_file { open
>>> } +	(( h1 dom h2 ) or ( t1 == mcsreadall ) or +	(( t1 != mcsuntrustedproc
>>> ) and ( t2 == domain ))); + +mlsconstrain { lnk_file chr_file blk_file
>>> sock_file } { getattr read ioctl } +	(( h1 dom h2 ) or ( t1 == mcsreadall
>>> ) or +	(( t1 != mcsuntrustedproc ) and (t2 == domain))); + +mlsconstrain
>>> { lnk_file chr_file blk_file sock_file } { write setattr } +	(( h1 dom h2
>>> ) or ( t1 == mcswriteall ) or +	(( t1 != mcsuntrustedproc ) and (t2 ==
>>> domain)));
>>>
>>> # New filesystem object labels must be dominated by the relabeling
>>> subject # clearance, also the objects are single-level. @@ -101,6 +117,12
>>> @@ mlsconstrain process { sigkill sigstop } (( h1 dom h2 ) or ( t1 ==
>>> mcskillall ));
>>>
>>> +mlsconstrain process { signal } +	(( h1 dom h2 ) or ( t1 !=
>>> mcsuntrustedproc )); + +mlsconstrain { tcp_socket udp_socket rawip_socket
>>> } node_bind +	(( h1 dom h2 ) or ( t1 != mcsuntrustedproc )); +
> 
>> This doesn't look right.  It says that only untrusted processes are
>> MCS-constrained for these permissions.
> 
> 
> Yes the idea we have moved to is to make MCS contraints opt in by the policy
> writer rather then optout.

Ok, then in that case, my preference would be to have it like ubac and have an attribute called mcsconstrained or mcs_constrained_type and the interface name changed accordingly.  Then it would be clearer that its an opt-in mechanism.

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