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
http://www.tresys.com | oss.tresys.com
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
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
http://www.tresys.com | oss.tresys.com
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
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
http://www.tresys.com | 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
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
> http://www.tresys.com | oss.tresys.com
>
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
> > http://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
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
>> > http://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
http://www.tresys.com | oss.tresys.com