From: chanson@TrustedCS.com (chanson at TrustedCS.com)
Date: Wed, 10 Nov 2010 09:49:20 -0500
Subject: [refpolicy] MLS unix socket sendto/connectto
References: <4CD2B2E6.4040501@tresys.com> <1288882009.5067.4.camel@sifl>	
	<4CD3F2BF.1050409@tresys.com> <1288960740.5152.1.camel@sifl>
	<4CD3FC1C.7010705@tresys.com>
Message-ID: <170D6ABBBA770349AA49582A86FCED150322F421@HAVOC.tcs-sec.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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
> >