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
> > http://www.tresys.com | oss.tresys.com
> >
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
>>> http://www.tresys.com | oss.tresys.com
>>>
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com