Pulling selected items out of Jarret’s email:
[A] Stupid opening question for Tom – the new –labeled- draft says the following in Section 1:
(1) Clients must be able to convey to the server the security
attribute of the subject making the access request. The server
may provide a mechanism to enforce MAC policy based on the
requesting subject's security attribute.
[... snip ...]
The ability to convey the
security attribute of the subject as described in requirement (1)
falls upon the RPC layer to implement.
Where is that proposed RPC change/addition specified? I didn’t see it in the –labeled- draft.
[B]
> Are we still missing the following use cases?
> - MAC in virtualized environment (EMC ?)
> - MAC in cloud computing (?)
> - additional use cases from Kathleen (?)
At least Kathleen and I are signed up to do something here. We’re not promising that all of these use cases are applicable to MAC, but we’ll take a serious look - stay tuned.
[C]
> - Mechanism to allow systems to advertise MAC attributes support
> Negotiated by requesting supported attributes from server (EXCHANGE_ID)
> May turn off support by not requesting attribute.
>
> Based on the known use cases, how sophisticated does this negotiation need to be? It's conceivable that a MAC
> system may be capable of supporting more than one label format. Is there a need for a system to express its full
> capability (e.g. I understand LSF 5 and 7)? BTW, the use cases that I know don't require that level of complexity.
If there’s a mismatch, client will discover quickly when a retrieved label has the wrong LFS value. This is indicative of a serious security misconfiguration (e.g., client SHOULD disconnect if an LFS value is unexpected).
In the other direction, how does a client announce whether it’s MAC capable? Note that this would be a config check mechanism (e.g., accidentally connected a non-MAC client to a MAC server that it’s not supposed to talk to), *not* a security mechanism, because a malicious client will lie.
[D]
> - Add text to better define support of full mode MAC security as implementation
> recommendations for servers not mandating it but rather MAY be implemented.
>
> I thought about this a bit more after the meeting. The protocol extension should be made to support full mode. I believe
> users who really care about MAC security want to operate in full mode.
This looks like violent agreement, at least to me. IMHO, as long as the protocol extension supports full MAC mode, but server implementation of MAC is optional (MAY or a qualified SHOULD, not MUST), I think everyone may be happy – a user who wants MAC server support configures the server to support MAC and perhaps also the clients to check for that support. In general, it looks like server MAC enforcement is a mostly transparent add-on for MAC-enabled clients (and ditto for MAC-ignorant clients).
[E]
> # full mode for pNFS
>
> If MAC negotiation/checks only happens between clients and MDS, this should work for pNFS, right?
Not necessarily, because pNFS bypasses the server, and hence bypasses any server MAC checks 
. If the client is making MAC checks, the pNFS metadata server is making MAC checks, but one or more of the pNFS data servers is/are not, the “users who really care about MAC security” may not be happy. Addressing this might just involve explaining what happens and recommending that people not do things that may not work out well (e.g., “users who really care about MAC security” SHOULD NOT use MAC-incapable data servers – for the pNFS block layout, I think this is a specific case of a “SHOULD NOT” security caution that’s already in RFC 5663).
[F]
> # delegations (directory and files?)
> Given MAC clients and MAC server are supposed to perform independent policy enforcement, the delegation
> feature probably does not make sense.
IMHO, file delegation is probably ok (server MAC check covering file access probably suffices for delegation). OTOH, directory delegation is problematic, and I would have no problem for 4.2 if we said that directory delegation SHOULD NOT (or even MUST NOT?) be used w/MAC, which is a step towards:
> 5. Add a section addressing the delegations and explain why delegations
> are non-goals for 4.2 and what will be the roadmap for adding delegation
> support in future versions.
[G]
> 7. Add explanation on the issues related to root protection and/or recommendation
> how to solve them in the server (or and client)
>
> I don't understand this. Is this related to prevention of privilege escalation?
No, some of the implementations apparently allow the root directory to be listed without MAC checks for reasons that I’ll leave to the implementers to explain. Something would be needed in the sequence of operations at mount time, or a recommendation for a workaround where the mounted root directory contains only one entry that is the logical root of the MAC-controlled filesytem (e.g., “secure_root” is the only directory entry in the mounted directory). Listing that entry should be relatively harmless.
Thanks,
--David
From: nfsv4-bounces <at> ietf.org [mailto:nfsv4-bounces <at> ietf.org] On Behalf Of jarrett.lu <at> oracle.com
Sent: Friday, April 01, 2011 7:17 AM
To: faibish, sorin; nfsv4 <at> ietf.org; thomas <at> netapp.com
Cc: Moriarty, Kathleen
Subject: Re: [nfsv4] Fwd: New Version Notification for draft-quigley-nfsv4-labeled-00
Tom,
Thank you for taking the initiative in consolidating the documents. Let's work on the consolidated document and try to get it in shape for IETF 81.
|
Re: [nfsv4] Fwd: New Version Notification for draft-quigley-nfsv4-labeled-00
|
|
Date: Thu, 31 Mar 2011 04:42:21 -0400 |
I want to start the discussion on the draft by adding the items and issues
we need to address in the draft based on my discussions with Jarrett
and included in the slides I didn't show in the WG meeting.
1. Add in the introduction in more detail what security issues are not
addressed by the current ACL that are resolved by the current draft.
Text in current document is sufficient. No additional action required.
2. Add more usecases at least usecases related to virtualization needs,
government usecases, Linux usecases, cloud possible usecases, additional
usecases from Kathleen (CCed) mentioned during the meeting.
Are we still missing the following use cases?
- MAC in virtualized environment (EMC ?)
- MAC in cloud computing (?)
- additional use cases from Kathleen (?)
Do we know who should provide what use cases? Someone should be assigned the action items to collect the known use cases. Sorin, should this person be you?
3. Add or group in one section addressing the implementation mechanism
and new xdr additions to make it clear for implementers.
Tom started doing that.
- Change MAC attributes to be represented as 2 separate entities:
Domain of Interpretation (DOI, specified by LFS)
Opaque without special separator <at>
This is agreed upon. Still need to specify format.
- Mechanism to allow systems to advertise MAC attributes support
Negotiated by requesting supported attributes from server (EXCHANGE_ID)
May turn off support by not requesting attribute.
Based on the known use cases, how sophisticated does this negotiation need to be? It's conceivable that a MAC system may be capable of supporting more than one label format. Is there a need for a system to express its full capability (e.g. I understand LSF 5 and 7)? BTW, the use cases that I know don't require that level of complexity.
- Define fixed max size of the opaque (not less than IPv6 HBH extension length?)
I suggested that because CALIPSO label is implement using IPv6 HBH extension. A CALIPSO label should fit in the opaque field.
- Add text to better define support of full mode MAC security as implementation
recommendations for servers not mandating it but rather MAY be implemented.
I thought about this a bit more after the meeting. The protocol extension should be made to support full mode. I believe users who really care about MAC security want to operate in full mode. Let's also examine each of the "half mode" operations and its impact on the protocol extension. (1) In the case that only server understands MAC, server can enforce its MAC policy without clients knowing it. When a non-MAC client requests access to a labeled file object (or its attributes), the server may grant access if its MAC policy allows it. When such access is granted, should the server hide the labeled attribute from the client? If so, there is no protocol impact, and there is no reason why older verson NFS clients can't be supported in this case. Otherwise, there is protocol impact and older version clients can't be supported without changes. (2) In the case where only client understands MAC, protocol extension is required because a client can request creation of a labeled object. The difference between this case and the "full mode" case is that a creation of a labeled object may fail in "full mode" if server MAC policy prevents it.
- Address different policy reinforcement implementations more clearily:
+ full server reinforcement only for dumb MAC unaware clients (define
how dumb, v2, v3, v4.0).
* Need to define/recommend which policies.
* Mention what are goals and non-goals addressed by current draf
# full mode for pNFS
If MAC negotiation/checks only happens betwen clients and MDS, this should work for pNFS, right?
# delegations (directory and files?)
Given MAC clients and MAC server are supposed to perform independent policy enforcement, the delegation feature probably does not make sense.
# untrusted devfelopments
* Separate "visibility" from "access permission" reinforcement.
+ server policy to just prevent non MAC aware clients access and see the
secured objects
+ full server policy reinforcements for MAC aware clients
We need to distinguish support for MAC label attribute and MAC policy. For example, a non-MAC server is capable of get/set MAC label attribute (just like any other file attribute) but can't enforce any MAC policies.
4. Include a section about the pNFS support where to mention why
pNFS is different than 4.1. The current explanation may not be
enough. I would also include the reasoning why named attributes
is not recommended to be used.
I don't think we want to leave named attributes as an option to implement MAC attribute, as named attribute does not meet the requirement. If this prevents MAC support in NFSv3, so be it.
5. Add a section addressing the delegations and explain why delegations
are non-goals for 4.2 and what will be the roadmap for adding delegation
support in future versions.
6. Define in more details all the behaviors: MAC aware cleint, MAC un-aware
clients, MAC supportive server, MAC aware server and full mode server.
7. Add explanation on the issues related to root protection and/or recommendation
how to solve them in the server (or and client)
I don't understand this. Is this related to prevention of privilege escalation?
8. Define the impact of new labels on dumb clients and MAC un-aware clients both
from perspective of backward compatibility (new labels not break the clients)
how to inform them that server will reinforce MAC (maybe?)
We discussed additional issues which I may forgot so please jump in
and add issues I missed that we will discuss during the calls. And I insist
of having bi-weekly calls as Jarrett, me and Dave recommend to have. It
worked good last time we had the series. Thank you very much for your
patience.
I suggest we start tracking issues and assigning action items to people. My impression is that if we need to include MAC support in 4.2, we need to make steady progress.
Thanks.
- Jarrett
/Sorin
RSS Feed