From: chanson@TrustedCS.com (chanson at TrustedCS.com)
Date: Fri, 5 Nov 2010 09:53:39 -0400
Subject: [refpolicy] MLS unix socket sendto/connectto
In-Reply-To: <4CD3FC1C.7010705@tresys.com>
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: <170D6ABBBA770349AA49582A86FCED15031B90F5@HAVOC.tcs-sec.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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
>