* [refpolicy] MLS unix socket sendto/connectto
@ 2010-11-04 13:19 Christopher J. PeBenito
2010-11-04 14:46 ` Paul Moore
0 siblings, 1 reply; 11+ messages in thread
From: Christopher J. PeBenito @ 2010-11-04 13:19 UTC (permalink / raw)
To: refpolicy
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?
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
^ permalink raw reply [flat|nested] 11+ messages in thread* [refpolicy] MLS unix socket sendto/connectto 2010-11-04 13:19 [refpolicy] MLS unix socket sendto/connectto Christopher J. PeBenito @ 2010-11-04 14:46 ` Paul Moore 2010-11-05 12:04 ` Christopher J. PeBenito 0 siblings, 1 reply; 11+ messages in thread From: Paul Moore @ 2010-11-04 14:46 UTC (permalink / raw) To: refpolicy 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. -- paul moore linux @ hp ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] MLS unix socket sendto/connectto 2010-11-04 14:46 ` Paul Moore @ 2010-11-05 12:04 ` Christopher J. PeBenito 2010-11-05 12:39 ` Paul Moore 0 siblings, 1 reply; 11+ messages in thread From: Christopher J. PeBenito @ 2010-11-05 12:04 UTC (permalink / raw) To: refpolicy 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? -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] MLS unix socket sendto/connectto 2010-11-05 12:04 ` Christopher J. PeBenito @ 2010-11-05 12:39 ` Paul Moore 2010-11-05 12:44 ` Christopher J. PeBenito 0 siblings, 1 reply; 11+ messages in thread From: Paul Moore @ 2010-11-05 12:39 UTC (permalink / raw) To: refpolicy 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. -- paul moore linux @ hp ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] MLS unix socket sendto/connectto 2010-11-05 12:39 ` Paul Moore @ 2010-11-05 12:44 ` Christopher J. PeBenito 2010-11-05 12:49 ` Paul Moore ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Christopher J. PeBenito @ 2010-11-05 12:44 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] MLS unix socket sendto/connectto 2010-11-05 12:44 ` Christopher J. PeBenito @ 2010-11-05 12:49 ` Paul Moore 2010-11-05 13:53 ` chanson at TrustedCS.com 2010-11-10 14:49 ` chanson at TrustedCS.com 2 siblings, 0 replies; 11+ messages in thread From: Paul Moore @ 2010-11-05 12:49 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] MLS unix socket sendto/connectto 2010-11-05 12:44 ` Christopher J. PeBenito 2010-11-05 12:49 ` Paul Moore @ 2010-11-05 13:53 ` chanson at TrustedCS.com 2010-11-10 4:45 ` HarryCiao 2010-11-10 14:49 ` chanson at TrustedCS.com 2 siblings, 1 reply; 11+ messages in thread From: chanson at TrustedCS.com @ 2010-11-05 13:53 UTC (permalink / raw) To: refpolicy 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] MLS unix socket sendto/connectto 2010-11-05 13:53 ` chanson at TrustedCS.com @ 2010-11-10 4:45 ` HarryCiao 2010-11-10 15:06 ` Christopher J. PeBenito 0 siblings, 1 reply; 11+ messages in thread From: HarryCiao @ 2010-11-10 4:45 UTC (permalink / raw) To: refpolicy Hi SELinux experts, 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). 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(). 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 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 > > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101110/8fff1883/attachment.html ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] MLS unix socket sendto/connectto 2010-11-10 4:45 ` HarryCiao @ 2010-11-10 15:06 ` Christopher J. PeBenito 0 siblings, 0 replies; 11+ messages in thread From: Christopher J. PeBenito @ 2010-11-10 15:06 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] MLS unix socket sendto/connectto 2010-11-05 12:44 ` Christopher J. PeBenito 2010-11-05 12:49 ` Paul Moore 2010-11-05 13:53 ` chanson at TrustedCS.com @ 2010-11-10 14:49 ` chanson at TrustedCS.com 2010-11-10 14:54 ` Christopher J. PeBenito 2 siblings, 1 reply; 11+ messages in thread From: chanson at TrustedCS.com @ 2010-11-10 14:49 UTC (permalink / raw) To: refpolicy 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 > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [refpolicy] MLS unix socket sendto/connectto 2010-11-10 14:49 ` chanson at TrustedCS.com @ 2010-11-10 14:54 ` Christopher J. PeBenito 0 siblings, 0 replies; 11+ messages in thread From: Christopher J. PeBenito @ 2010-11-10 14:54 UTC (permalink / raw) To: refpolicy 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 >>> www.tresys.com | oss.tresys.com >>> -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-11-10 15:06 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-04 13:19 [refpolicy] MLS unix socket sendto/connectto Christopher J. PeBenito 2010-11-04 14:46 ` Paul Moore 2010-11-05 12:04 ` Christopher J. PeBenito 2010-11-05 12:39 ` Paul Moore 2010-11-05 12:44 ` Christopher J. PeBenito 2010-11-05 12:49 ` Paul Moore 2010-11-05 13:53 ` chanson at TrustedCS.com 2010-11-10 4:45 ` HarryCiao 2010-11-10 15:06 ` Christopher J. PeBenito 2010-11-10 14:49 ` chanson at TrustedCS.com 2010-11-10 14:54 ` Christopher J. PeBenito
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.