From: paul.moore@hp.com (Paul Moore)
Date: Fri, 05 Nov 2010 08:49:01 -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: <1288961341.5152.3.camel@sifl>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, 2010-11-05 at 08:44 -0400, Christopher J. PeBenito wrote:
> 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.

Sorry.  You were showing the MLS constraints for unix sockets so I
thought that is what you were concerned about.

-- 
paul moore
linux @ hp