Subject: RE: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

From: "Halevy, Benny" <[email-masked]>
Date: Thu, 11 Nov 2004 04:30:35 -0500

> I think the only requirement should be that the data servers 
> respond to
> IO requests in way which is consistent with the ACL set on the server.

I agree completely with that requirement.  I think it is better to
leave some freedom of choice to the implementer as long as the
implementation provides the required semantics.  What described
in the I-D should be phrased as an example not as a requirement.

Benny

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Noveck, Dave
> Sent: Wednesday, November 10, 2004 10:17 PM
> To: William A.(Andy) Adamson; Mike Eisler
> Cc: [email-masked]
> Subject: RE: [nfsv4] comments on draft-welch-pnfs-ops-00.txt 
> 
> 
> > > > 4.2 File Security
> > > > 
> > > > 
> > > >   The file storage protocol has the same security mechanism
> between
> > > >   the client and metadata server as between the client and data
> server.
> > > >   This implies that the files that store the data need the same
> ACL as
> > > >   the metadata file that represents the "control point" for the
> file.
> > > >   This ensures that access control decisions are consistent
> between
> > > >   the metadata server and the data server.
> > 
> > this is easy. a file that is created over pNFS with a file layout
> (stripped 
> > across NFSv4 'data servers') will naturally all have the same acl.
> 
> Well when a SETATTR changed the ACL, it would have to propagated to
> all of the metadata servers (via the storage management protocol) and,
> if the server went down, you would need to deal with the issue of the 
> ACL's being different on different stripes and how to repair that.
> 
> What is easy in prototype mode may not so easy in shipping product
> mode, which is something we all have to deal with.
> 
> The pragraph quoted above suggests that the each of stripe files have
> to have the same ACL and that can pose difficulties and I think that
> they can avoided.  As written, the paragraph (seems to) suggest that 
> the clients could do individual GETATTR(ACL)'s and it is a requirement
> that the clients gets back an ACL that matches the one on the metadata
> server.
> 
> I think the only requirement should be that the data servers 
> respond to
> IO requests in way which is consistent with the ACL set on the server.
> If you want to not store the ACL on the data servers and have them get
> the information on which principals have what access to which files 
> from the metadata server, and cache that information and 
> flush it when 
> the metadata server tells them it changes, then that should 
> be allowed. 
> 
> 
> -----Original Message-----
> From: William A.(Andy) Adamson [mailto:[email-masked]] 
> Sent: Wednesday, November 10, 2004 12:39 PM
> To: Mike Eisler
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nfsv4] comments on draft-welch-pnfs-ops-00.txt 
> 
> 
> > My comments are around the security area.
> > 
> > It isn't clear why new authentication systems are being invented
> > here, when we alread have one: ONC RPC authentication flavors, and
> > specifically, RPCSEC_GSS. The i-d needs to justify its direction.
> 
> i don't get what you mean. new authentication systems are not being
> invented. 
> the intent is to use and existing storage protocol security features, 
> including rpcsec_gss when present (not block layout, not OSD layout,
> only file 
> layout).
> 
> > 
> > > 4.1 Object Storage Security
> > > 
> > > 
> > >   The object storage protocol relies on a cryptographically secure
> > >   capability to control accesses at the object storage devices.
> > >   Capabilities are generated by the metadata server, 
> returned to the
> > >   client, and passed to the object storage device, which verifies
> > >   that the capability allows the requested operation.
> > > 
> > > 
> > >   Each capability is specific to a particular object, an operation
> > >   on that object, a byte range w/in the object, and has 
> an explicit
> > >   expiration time.  The capabilities are signed with a secret key
> > >   that is shared by the object storage devices (OSD) and the
> metadata
> > >   managers.  Typically each OSD has a set of master keys 
> and working
> > >   keys, and the working keys are rotated periodically under the
> > >   control of the metadata manager.  Clients do not have 
> device keys
> > >   so they are unable to forge capabilities.  Capabilities need to
> > >   be protected from snooping, which can be done by using 
> facilities
> > >   such as Ipsec to create a secure VPN that contains the clients,
> > >   the file server, and the storage devices.
> > 
> > Requiring IPsec to protect the capabilities strikes me as
> > overkill.
> > 
> > Why doesn't the protocol assign each user a session key
> > known to metadata server and OSD, and then use the session
> > key to compute an HMAC on some or all of the messages?
> > GSS-API would be the ideal way to wrap an HMAC.
> 
> ok - but using an HMAC is a change to the storage protocol, the use of
> ipsec 
> is not.
> 
> pNFS might need an operation to communicate the OSD capabilities from
> the 
> NFSv4 server to the pNFS client....
> > 
> > > 4.2 File Security
> > > 
> > > 
> > >   The file storage protocol has the same security 
> mechanism between
> > >   the client and metadata server as between the client and data
> server.
> > >   This implies that the files that store the data need 
> the same ACL
> as
> > >   the metadata file that represents the "control point" for the
> file.
> > >   This ensures that access control decisions are 
> consistent between
> > >   the metadata server and the data server.
> 
> this is easy. a file that is created over pNFS with a file layout
> (stripped 
> across NFSv4 'data servers') will naturally all have the same acl.
> 
> > > 
> > > 
> > >   One alternative that was briefly discussed was the introduction
> > >   of special file handles that essentially have the properties of
> > >   capabilities so they can be generated by the metadata 
> servers and
> > >   checked by the data servers.  (Peter Corbett described 
> "one shot"
> > >   file handles.)  To be effective, these need all the 
> properties of
> a
> > >   capability so the data server can efficiently and 
> securely enforce
> > >   the access control decisions made by the metadata manager.
> 
> i don't see a need for special file handles, or to discuss 
> capabilities
> in the 
> file layout case.
> 
> > The problem with opaque special file handles is that presumably each
> > user of a given file gets his own file handle. This means 
> NFS clients
> > are going cache multiple copies of the same data.
> > 
> > Assuming the capability route is going to be taken (a huge 
> assumption,
> > IMHO), why not introduce a new NFSv4 pseudo op, (say 
> "PUT_CAP") which
> injects
> > a capability into the COMPOUND procedure's operations stream?
> > 
> > > 
> > >   [We need to elaborate on this section. We should be able to
> > >   leverage the NFSv4 GSS context between the client and the NFSv4
> > >   "Storage Devices".]
> > 
> > If this is the direection, then at minimum the paragraph previous
> > to this should be struck. But to beat the not quite dead horse,
> > it is unclear why RPCSEC_GSS can't be used as is.
> > 
> > > 4.3 Block Security
> > > 
> > > 
> > >   The block model relies on SAN-based security, and trusts that
> > >   clients will only access the blocks they have been directed to
> use.
> > >   In these systems, there may not need to be any 
> additional security
> > >   information returned with the map.  There are LUN
> masking/unmapping
> > >   and zone-based security schemes that can be manipulated to fence
> > >   clients from each other's data.  These are fairly heavy weight
> > >   operations that are not expected to be part of the normal
> execution
> > >   path for pNFS. But, a metadata server can always fall back to
> these
> > >   mechanisms if it needs to prevent a client from 
> accessing storage
> > >   (i.e., "fence the client".)
> > 
> > Here I can accept that RPCSEC_GSS-like system 
> authenticating a blocks
> protocol
> > isn't going to happen, mostly because blocks protocols have no
> > provision for real authentication. That said, at the recent NAS
> conference,
> > when the issue was raised, I thought I'd understood Brent Welch
> > to say that capabilities could be added to the blocks protocol.
> > If so, couldn't a capability, mutually signed by the metadata server
> and the NFS
> > server, could be used?
> > 
> 
> we can certainly influence storage protocols so that they play better
> with pNFS security, but at the end of the day, we take what 
> we get which
> in the current block world is nothing. adding a capabilty to the block
> protocol is outside the scope of pnfs. running the block protocol over
> ipsec is once again a consideration.
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Nov 2004 22:43:45 -0600

> in the I-D should be phrased as an example not as a requirement.

It should be a requirement, yes, but IMO there must be at least one
REQUIRED-to-implement mode of pNFS that provides this in a reasonable
and deployable way.

Nico
--