From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Fri, 05 Nov 2010 08:04:15 -0400
Subject: [refpolicy] MLS unix socket sendto/connectto
In-Reply-To: <1288882009.5067.4.camel@sifl>
References: <4CD2B2E6.4040501@tresys.com> <1288882009.5067.4.camel@sifl>
Message-ID: <4CD3F2BF.1050409@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 11/04/10 10:46, Paul Moore wrote:
> On Thu, 2010-11-04 at 09:19 -0400, Christopher J. PeBenito wrote:
>> The current MLS constraints for unix socket sendto/connectto are:
>>
>> # UNIX domain socket ops
>> mlsconstrain unix_stream_socket connectto
>>         (( l1 eq l2 ) or
>>          (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby
>> h2 )) or
>>          (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2
>> )) or
>>          ( t1 == mlsnetwrite ) or
>>          ( t2 == mlstrustedobject ));
>>
>> mlsconstrain unix_dgram_socket sendto
>>         (( l1 eq l2 ) or
>>          (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby
>> h2 )) or
>>          (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2
>> )) or
>>          ( t1 == mlsnetwrite ) or
>>          ( t2 == mlstrustedobject ));
>>
>> These were added earlier this year (except the last t2 exception which
>> was added more recently).  My concern is with the mlstrustedobject part.
>>  We need an exception like this to handle domains such as syslog, so
>> they can receive messages from any level.  But I think we need a
>> different attribute since domain types are used for the process itself
>> and also it's /proc/pid files, so by making the domain a trusted object,
>> the /proc/pid become trusted objects too.  Opinions?
> 
> Is there a reason why we don't have transition rules for things like
> sockets?  Granted, they are probably only useful for unix sockets, but I
> think they could come in handy for things like this where we don't want
> to start messing around with adding setsockcreatecon() calls to the
> code.

I don't understand; how would a transition help here?

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