Interface for DOI mapping

Interface for DOI mapping

[Dave Quigley]

Hello,
    With help from Neil I have the actual daemon code working for DOI
translations. Now I have to come up with an interface for allowing an
LSM to specify its translations. Either in the form of a separate
library or in the daemon code itself I intend to dlopen a shared library
and make calls into it. The question is what functionality do we want
here and where should it be placed. 

In the long run it would be nice to have a server which maintains the
mappings for all of the clients in its domain similar to kerberos.
However the client also needs to be able to operate without such a
server. 

If you have suggestions for this feel free to make them now while I am
still designing this.

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Interface for DOI mapping

[Paul Moore]

On Monday 03 December 2007 3:32:45 pm Dave Quigley wrote:
>     With help from Neil I have the actual daemon code working for DOI
> translations. Now I have to come up with an interface for allowing an
> LSM to specify its translations. Either in the form of a separate
> library or in the daemon code itself I intend to dlopen a shared library
> and make calls into it. The question is what functionality do we want
> here and where should it be placed.
>
> In the long run it would be nice to have a server which maintains the
> mappings for all of the clients in its domain similar to kerberos.
> However the client also needs to be able to operate without such a
> server.
>
> If you have suggestions for this feel free to make them now while I am
> still designing this.

The first question that immediately springs to mind is "which DOI?"  I know 
you are currently focused on labeled NFS and how to translate file labels 
between different MAC implementations but I think it is worthwhile to broaden 
the scope of the DOI translation effort.  I know that both CIPSO and labeled 
IPsec have DOI attributes and a proper DOI translation mechanism could have 
benefits here too.  There are probably others (labeled X? labeled databases?) 
but I'm not knowledgeable enough in those areas to say for certain.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Interface for DOI mapping

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:

> On Monday 03 December 2007 3:32:45 pm Dave Quigley wrote:
> >     With help from Neil I have the actual daemon code working for DOI
> > translations. Now I have to come up with an interface for allowing an
> > LSM to specify its translations. Either in the form of a separate
> > library or in the daemon code itself I intend to dlopen a shared library
> > and make calls into it. The question is what functionality do we want
> > here and where should it be placed.
> >
> > In the long run it would be nice to have a server which maintains the
> > mappings for all of the clients in its domain similar to kerberos.
> > However the client also needs to be able to operate without such a
> > server.
> >
> > If you have suggestions for this feel free to make them now while I am
> > still designing this.
> 
> The first question that immediately springs to mind is "which DOI?"  I know 
> you are currently focused on labeled NFS and how to translate file labels 
> between different MAC implementations but I think it is worthwhile to broaden
> 
> the scope of the DOI translation effort.  I know that both CIPSO and labeled 
> IPsec have DOI attributes and a proper DOI translation mechanism could have 
> benefits here too.  There are probably others (labeled X? labeled databases?)

I strongly encourage everyone to have a look at the Mitre CMW
label mapping scheme (I'm sure someone can dredge it up from
somewhere, I unfortunatly don't have it handy) and put it on the
table as a really bad option. In it's a attempts to be general
it demonstrates just how hard it is to do meaningful mappings
between DOIs.

What I do recomend is a table in the form:

    DOI1:value1:DOI2:value2

Where each entry is interpreted as a one way translation.
For example:

   801:juan:906:wendy

would say that if you're in DOI 906, and you're presented with
"juan" from DOI 801 you would use "wendy" locally. It does not
mean that if you know what to send back, if the mapping is
reflexive you would also need

   906:wendy:801:juan

Why? Consider an environment where MLS is in use on one
machine, but not another. You might want to map

   906:vampire_t:801:redcross_t
   906:werewolf_t:801:redcross_t

inbound but provide a different value on the way back
to reflect that fact that you don't know which it was coming in

  801:redcross_t:906:nocturnal_t

and let the far end deal with the details of making this work.

which brings up the question of who does the translation.
I suggest that the receiver always do the mapping and that the
sender always speaks it's native DOI. 


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Interface for DOI mapping

[Paul Moore]

On Tuesday 04 December 2007 12:10:15 pm Casey Schaufler wrote:
> which brings up the question of who does the translation.
> I suggest that the receiver always do the mapping and that the
> sender always speaks it's native DOI.

You've got more experience in this area than I do, but I would think that 
offering translations about on the sender and receiver would be necessary to 
handle both new hosts (systems that support multiple DOIs through 
translation) as well as legacy hosts (systems that only support a single 
DOI).  In the case of a receiver that supports DOI translation, I agree, it 
probably is best for the sender to send data using it's default/native DOI 
and let the receiver translate as necessary.  However, if the receiver does 
not understand multiple DOIs it will be necessary for the sender to ensure 
that data sent to the receiver it sent with the receiver's DOI; requiring the 
use of sender side DOI translation in certain cases.

In either case, I think a properly designed and configured system would only 
want to perform the translation once.  Although there shouldn't be anything 
preventing someone for configuring the translation to happen on both ends if 
that is what they really want.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Interface for DOI mapping

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:

> On Tuesday 04 December 2007 12:10:15 pm Casey Schaufler wrote:
> > which brings up the question of who does the translation.
> > I suggest that the receiver always do the mapping and that the
> > sender always speaks it's native DOI.
> 
> You've got more experience in this area than I do, but I would think that 
> offering translations about on the sender and receiver would be necessary to 
> handle both new hosts (systems that support multiple DOIs through 
> translation) as well as legacy hosts (systems that only support a single 
> DOI).  In the case of a receiver that supports DOI translation, I agree, it 
> probably is best for the sender to send data using it's default/native DOI 
> and let the receiver translate as necessary.  However, if the receiver does 
> not understand multiple DOIs it will be necessary for the sender to ensure 
> that data sent to the receiver it sent with the receiver's DOI; requiring the
> 
> use of sender side DOI translation in certain cases.
> 
> In either case, I think a properly designed and configured system would only 
> want to perform the translation once.  Although there shouldn't be anything 
> preventing someone for configuring the translation to happen on both ends if 
> that is what they really want.

Yeah, you're probably right with regard to systems that can't do
translation. What I think is important is that the translation be
a simple lookup rather than an attempt to interpret the attribute
data and reinterpret it for the other DOI.


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.