[refpolicy] MLS unix socket sendto/connectto

[Christopher J. PeBenito]

I think I would go with mlstrustedsocket, in case we end up needing it
for other socket types.

On 11/10/10 09:49, chanson at TrustedCS.com wrote:
> I'm actually thinking we want to have a new attribute, like
> mlstrustedsocket or mlstrustedunixsocket, to replace the
> mlstrustedobject on these constraints. I agree with the earlier comments
> that mlstrustedobject doesn't seem right for this constraint. I would
> say this because the most of the time the "object" of these unix domain
> sockets constraints is a process (domain) which is not desired to be a
> trusted object. 
> 
> This would simplify your policy changes as well. 
> 
> -Chad
>  
>> -----Original Message-----
>> From: Chad Hanson 
>> Sent: Friday, November 05, 2010 9:54 AM
>> To: 'Christopher J. PeBenito'; Paul Moore
>> Cc: Stephen Smalley; Daniel J Walsh; refpolicy at oss.tresys.com
>> Subject: RE: MLS unix socket sendto/connectto
>>
>> Thanks, Chris for the clarification. I tend to agree that we 
>> should have something different as we don't want this on a 
>> process per your proc pid example. Let me think about this a 
>> little bit.
>>
>> -Chad 
>>
>>> -----Original Message-----
>>> From: Christopher J. PeBenito [mailto:cpebenito at tresys.com]
>>> Sent: Friday, November 05, 2010 8:44 AM
>>> To: Paul Moore
>>> Cc: Stephen Smalley; Daniel J Walsh; Chad Hanson; 
>>> refpolicy at oss.tresys.com
>>> Subject: Re: MLS unix socket sendto/connectto
>>>
>>> On 11/05/10 08:39, Paul Moore wrote:
>>>> On Fri, 2010-11-05 at 08:04 -0400, Christopher J. PeBenito wrote:
>>>>> 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?
>>>>
>>>> I was thinking that a type transition could be used when
>>> /dev/log was
>>>> created so that it could be created with a new type which 
>> we could 
>>>> assign to the mlstrustedobject attribute.
>>>
>>> Wrong check.  The check on /dev/log is a sock_file check 
>> (eg foo_t to 
>>> devlog_t).  The above constraints are for foo_t to syslogd_t, as an 
>>> example.
>>>
>>>
>>>
>>> --
>>> Chris PeBenito
>>> Tresys Technology, LLC
>>> www.tresys.com | oss.tresys.com
>>>


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