Re: [Labeled-nfs] New MAC label support Internet Draft posted to IETF website
Jarrett Lu <Jarrett.Lu <at> Sun.COM>
2009-04-01 07:46:58 GMT
On 3/31/2009 7:47 AM, Paul Moore wrote:
On Monday 30 March 2009 11:07:02 pm Casey Schaufler wrote:
Jarrett Lu wrote:
I'm with Casey, I don't think it is worth spending a whole lot of time right
now finding out how to pass information across the network in a secure manner.
There are plenty of ways of to do that which are well established,
interoperable and generally regarded as "secure".
Maybe we can do something better 15 years later. The first step is to
figure out how much information is needed and then look into how to
get this info across securely. GSS_SEC may be able to help us. To make
NFSv4 work, only TCP is needed. So peer information is needed per
session vs. per packet, I believe. Evidently, there is more work to do
in figuring this all out.
Not to throw a puppy in the gears, but sophisticated handshaking and
negotiation protocols are not the answer. We had TSIG session management
for doing that and it is just not enough. How would you negotiate the
differences between two SELinux policies?
I'm not reinventing another secure way to pass information. I thought
kerberos gss api may be a good candidate. I also agree that
sophisticated handshaking negotiation protocol or complicated security
attribute mapping between various systems is not the way to go.
From my point of view the real issue is how do we translate/resolve security
labels defined by DOI X to an internal, security model/policy specific label?
Some have mentioned a mechanism which would serve up label encoding data
whenever a new system joined the network; unfortunately, I believe this only
works when you know the security policy of the system before hand (or can
restrict the security policy, after all a TSOL label encodings file will do
nothing for SELinux and/or Smack). While I think it is reasonable to assume a
limited number of on-the-wire label encodings and DOIs I think it would be a
mistake to assume a limited number of security models and or policies.
True. The first question is whether we should try to solve, or at least
ease, the label interpretation / translation problem in the context of
NFSv4 protocol. I don't know if we can solve it, but it seems
worthwhile to explore further, to gain more understanding if nothing
else. The challenge of interpreting and translating labels is that one
system needs to know a lot of info about its peer. And there is no good
way to describe the (sometimes subtle) difference. I think this problem
may be harder on DTE systems than on MLS systems, I believe.
Ultimately I believe that the required label translation information (wire/DOI
label to internal and the other way around) is going to need to be bundled
with the system's security policy and distributed as a single "package".
Granted this does require prior knowledge of the DOIs in use but I believe
this is a much easier requirement than the opposite. From a practical point
of view this isn't too far removed from the notion of sending sending label
encoding data upon joining the network, the big difference is that we are
sending both security policy and label encoding/DOI-translation data at the
same time (in the TSOL case I suspect this would just be the label encoding
data, which may mean the original poster had this in mind).
Depending how different the systems are, the "package" content will be
different. Assuming we can assemble all the information required to do
label translation correctly into a package, passing that around the
systems seem inefficient, non-scalable, and probably outside the scope
of labeled NFSv4 enhancement. So realistically, I think the DOI +
opaque label is useful between very compatible systems. Given that
limitation, may be the "package" is small enough and can be passed in
RPC layer during authentication so that MLS can share files with like
MLS systems, and same is true for DTE, fmac, smack, ....
nfsv4 mailing list
nfsv4 <at> ietf.org