From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Wed, 10 Nov 2010 10:06:10 -0500 Subject: [refpolicy] MLS unix socket sendto/connectto In-Reply-To: References: <4CD2B2E6.4040501@tresys.com> <1288882009.5067.4.camel@sifl>, <4CD3F2BF.1050409@tresys.com> <1288960740.5152.1.camel@sifl>, <4CD3FC1C.7010705@tresys.com>, <170D6ABBBA770349AA49582A86FCED15031B90F5@HAVOC.tcs-sec.com> Message-ID: <4CDAB4E2.1080305@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 11/09/10 23:45, HarryCiao wrote: > I read your discussion thread, it seems that we would think about using > the type_transition rule to define a new type for the UNIX socket > created by a domain, which we could add to the mlstrustedobject > attribute, rather than the creator's domain(say syslogd_t) to this > attribute(Similar to what the files_xxxx_filetrans() interface does). The problem is that there isn't a container or related type to transition over. For example, for syslog's socket there is the following type_transition: type_transition syslogd_t device_t:sock_file devlog_t; in this case, device_t is the type of the directory in which syslog creates the socket. But what would be the related type for sockets? > Or, alternatively we could call setsockcreratecon() in syslog-ng source > code to specify the new type for the socket syslogd created, but as Paul > suggested, this would mean that we would have to mess around the > userspace applications by adding the call of setsockcreratecon(). Correct, we'd rather not require all syslog daemons to be modified so they work right with the policy. > Have I got it? > > Thanks, > Harry > > >> Date: Fri, 5 Nov 2010 09:53:39 -0400 >> From: chanson at TrustedCS.com >> To: cpebenito at tresys.com; paul.moore at hp.com >> CC: refpolicy at oss.tresys.com >> Subject: Re: [refpolicy] MLS unix socket sendto/connectto >> >> Thanks, Chris for the clarificatio n. 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 >> > >> _______________________________________________ >> refpolicy mailing list >> refpolicy at oss.tresys.com >> http://oss.tresys.com/mailman/listinfo/refpolicy > * -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com