Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: Interface for DOI mapping Date: Mon, 03 Dec 2007 15:32:45 -0500
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.From: Paul Moore <paul.moore_at_hp.com> subject: Re: Interface for DOI mapping Date: Mon, 3 Dec 2007 16:16:02 -0500
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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Interface for DOI mapping Date: Tue, 4 Dec 2007 09:10:15 -0800 (PST)
> On Monday 03 December 2007 3:32:45 pm Dave Quigley wrote: 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
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
-- 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.From: Paul Moore <paul.moore_at_hp.com> subject: Re: Interface for DOI mapping Date: Tue, 4 Dec 2007 13:49:39 -0500
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.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: Interface for DOI mapping Date: Tue, 4 Dec 2007 11:12:15 -0800 (PST)
> On Tuesday 04 December 2007 12:10:15 pm Casey Schaufler wrote: 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
-- 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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |