[Lustre-devel] Security issues
Eric.Mei at Sun.COM
Fri Aug 8 10:44:06 PDT 2008
Peter Braam wrote:
> On 8/8/08 11:03 AM, "Eric Barton" <eeb at sun.com> wrote:
> 1. Securing bulk data.
> It seems to me that it _is_ appropriate to use the GSSAPI to secure the
> transfer of bulk data between client and server since it's
> effectively just
> another message. I can see (at least naively) that it would be good to
> avoid double encryption in the case where file contents are actually
> encrypted on disk.
> You are not telling me that we are going through a lot of re-design,
> that we are encrypting data and that then we are not storing it
> encrypted on disk? Come on, adding an EA with a key to decrypt is not
> so hard and one gets lots of value from it.
> But even in this case, don't we still have to sign the
> (encrypted) bulk so that the receiver can be sure it arrived intact?
> Well, yes, but as I indicated you can sign the hash that is stored on
> (ZFS) disk for this. That avoids generating the hash twice. So I am
> really not convinced yet.
Peter, are you saying that except using NASD-style protocol, we don't
need to encrypt/sign bulk data at all?
> The issue is not the message mechanism, but is what identity to use for
> GSS to authenticate and how to manage and revoke that etc.
Here we only want to protect on-wire data, the gss authentication is
only for the "node", not particular user, as you pointed out previously.
> 2. Securing Capabilities.
> If we want to be sure that a Capability given to client A cannot be
> snooped and used by client B we either (a) have to make the Capability
> secret (i.e. never passed in cleartext) or (b) have to make the
> identify which client it is valid for.
> It seems to me that (b) is preferrable since it ensures that a malicious
> client cannot leak Capabilities to a 3rd party. The downside is
> that this
> multiplies the number of unique Capabilities by the number of clients,
> potentially increasing CPU load when 1000s of clients all open the same
> shared file and each require unique Capabilities to access the
> stripe objects.
> Do we have a feel for how bad this could be?
> Yes, very bad, and it is absolutely necessary to have an option that
> avoids this (also 1000s is out of date – it could be 100x worse). That
> option could be to simply not have security on the compute cluster if
> customers agree with this.
> We also need to discuss your proposals with a review committee from LLNL
> and Sandia, as we did during the PF discussions.
We're trying to figure out a way to generate only one capability for
each MD object, but somehow mingled with per-export data to generate
client-unique capability, but till now we haven't found a good solution.
The other thought is using some kind of light-weight, but still
reasonably secure hash algorithm. By changing the KEY frequently enough
(e.g. every 2 hours) we can still be secure. But we'v no idea what hash
algorithm could fit our needs.
More information about the lustre-devel