Subject: [nfsv4] LNFS - Config check functionality?

From: <[email-masked]>
Date: Tue, 17 May 2011 19:38:37 -0400

In doing the analysis that lead to my previous message about partial
MAC support in servers being interesting, we stumbled across a
potential area of functionality - the purpose of this message is
to describe the functionality and solicit comments on interest and
importance.  I don't view it as absolutely essential, but it could
be useful in practice.

The functionality is for a client and server that both have some
degree of LNFS support (this includes a simple object-label-only
server that does no MAC enforcement) to exchange information about
MAC functionality when the client first contacts the server.  The
intent is to catch configuration errors (e.g., some host rebooted
and reverted to an earlier bad configuration without anyone noticing).

This sort of mechanism can only be used in a controlled environment
where the client is trusted, as an untrusted malicious client could
lie in whatever fashion is necessary to obtain access.  For what
to do about untrusted potentially malicious clients, see the
virtualization use case discussion in my other message about
partial MAC functionality in servers.

The proposed functionality (credit to Tom Haynes for some of this
design) is an EXCHANGE_LABEL operation that allows the client to
announce what it is doing - the server response is limited to Yes
("That's fine") or No ("Something's wrong - go away"), and because
the client is trusted, we can rely on it to send correct information
and go away when told to do so.  At a minimum, the client could
announce the LFS (label formats) that it requires support for based
on the DOI that it's operating under. If the server doesn't support
all of the required formats, the server says "No", causing a clean
client failure at mount time before any data has been accessed.

This could be extended to pass some sort of identification for the
configuration of the MAC policy at the client - this makes the NFS
server a central point for checking that all the clients have been
updated and stay updated, as the check occurs on every client mount.

Is this functionality useful and likely to be important in practice?
In particular, are the configuration mistakes that this will catch
likely to be common enough with serious enough consequences that it's
worth putting in protocol support to defend against them, which in
turn probably requires additional administrative activity to configure
the protocol support?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Nico Williams <[email-masked]>
Date: Tue, 17 May 2011 19:21:37 -0500

Solaris TX didn't need any of this.  It is possible to have MAC
enforcement w/o protocol extensions of any kind, provided one is
willing to impose some distributed configuration policy.

Since policy must be distributed in such cases, I don't really see the
value of adding protocol elements to verify that clients and servers
have the same policy.  Instead the policy distribution mechanism(s)
must be robust and distributed.

The bigger issue for this kind of deployment is going to be
configuration schema and distribution interoperability.  If you're
serious about standardizing this approach then you should consider
standardizing a schema and distribution method.  Say, LDAP, or XML
with policy fetched via NFS.  Or some such scheme.

I think four MAC enforcement models is a bit ambitious.  Consider what
it means in terms of implementation...  But then, MAC policy /
configuration distribution and interoperability are going to be an
issue for the full-fledged smart server MAC enforcement model too,
because even then we want smart clients when we want multi-label
clients.

Nico
--