Subject: [nfsv4] Labeled NFS - agenda bashing for the first meeting

From: Thomas Haynes <[email-masked]>
Date: Mon, 11 Apr 2011 10:09:09 -0500

I'm trying to bash out an agenda for the first meeting. At a high level, I have:

IETF Note Well Agreement
Kathleen - use cases 
Nico - RPCSEC_GSSv3

While the RPCSEC_GSSv3 stuff might make more sense in the NFSv4.2 meeting,
most of the discussion for it is in the context of LNFS.

The tone I'd like to set for the first couple of meetings is nailing down the use
cases to make sure our proposed design will work. Once we are convinced
of that, I'd like us to start in on the deep dives we've seen on the mailing lists.

If you have proposed agenda items that fit with that vision (or want to whack
me on the head with a new vision), feel free to respond on the WG alias.

----

PS:

  Time: Thursdays 12:30-1:30 PM CST/1:30-2:30 PM EST/10:30-11:30 AM PST
Dial-in: 1-888-765-3653 (us)
         303-218-2659 (international)
     Id: 2787108

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 10:21:52 -0500

Having much less of a stake in RPCSEC_GSSv3 (and NFSv4) than I used
to, I'd rather focus my energy on what I can bring to the table:
addressing technical issues that come up and related issues with the
I-D text.  I've already brought a fair bit of energy on use cases, but
that's not really a good use of my volunteer time at this time, so
I'll bow out of that discussion.  Of course, I think use cases are
pretty much addressed already on the list (and we seem to have fairly
strong consensus on the need for RPCSEC_GSSv3 in the more desirable
LNFS use cases, as well as in non-LNFS use cases as well), leaving
mostly a need to write up the use cases -- something I'm not
interested in doing at this time.

To this end, an eventual meeting that focuses primarily on technical
issues with RPCSEC_GSSv3 as it stands will be quite useful,
particularly given that the current design seems fairly close to ready
(we need to absorb recent implementor comments, implying minor
changes), though I agree that use cases should come first.

Nico
--

---

From: sfaibish <[email-masked]>
Date: Wed, 13 Apr 2011 11:55:38 -0400

> me on the head with a new vision), feel free to respond on the WG alias.

1. Discuss the usecases from Dan Walsh and Kathlyn. To be included in the
    I-D. (I will send preliminary definitions before the call)

2. Discuss the relation between RPCSEC_GSSv3 and LNFS related to:
- mount of NFS by MAC unaware clients on server supporting LNFS but not
   reinforcing MAC. (kerberos key manipulation)
- visibility of objects with no security label on servers supporting LNFS.
- minimum requirements for access to LNFS using default labels for unaware
   clients

There are additional items but I think this will be enough for first
call. Please comment on my proposed items if it doesn't make sense.

/Sorin

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

-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
         EMC²
where information lives

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: "Sorin Faibish" <[email-masked]>
Date: Thu, 14 Apr 2011 08:16:41 -0400

> I'm trying to bash out an agenda for the first meeting. At a high level,  
One of my Action Items for this call was to get a more detailed description
of the usecases from Dan Walsh fromn RedHat. This is what Dan provided:

	"I think there are three use cases.

	1. Secure virtualization, to allow me to prevent one
	   virtual machine from attacking another virtual
	   machines image when stored on shared NFS storage.
	2. Sandboxing.  Allows me to isolate multiple
	   "namespaced" homedirs on my homedir.  If the
	   homedir is nfs.
	3. NFS homedir labeling to handle process separation.

	The way secure virtualization works:
	The libvirt daemon selects a label for a process and
	one or more labels for the images associated with the
	virtual machine. Their could be a rw label, ro label
	maybe others.  Then libvirt generates a random "MCS"
	label that it addes to all the Security label.
	libvirt then changes the extended attributes with
	these file labels and finally launches the virtual
	machine process with a label to match.

	These labels look like

	Process Label -> system_u:system_r:svirt_t:s0:c102,c423
	Image File Label -> system_u:object_r:svirt_image_t:s0:c102,c423

	Another virtual machine might look like:

	Process Label -> system_u:system_r:svirt_t:s0:c12,c375
	Image File Label -> system_u:object_r:svirt_image_t:s0:c12,c375

	Then the SELinux kernel ensures that
	system_u:system_r:svirt_t:s0:c12,c375 can NOT interface with process
	system_u:system_r:svirt_t:s0:c102,c423
	and image system_u:object_r:svirt_image_t:s0:c102,c423

	Currently since nfs does not support labeling we label all nfs shares
	the same by default

	system_u:object_r:nfs_t:s0

	This means we either allow or deny all svirt_t process labels full
	access to nfs_t or no access to nfs_t.  Meaning people who want to build
	virtualization/clouds using images shared over NFS either can not use
	NFS or do not get sVirt protection.

	The sandbox use case is similar.

	In the homedir use case we are getting more specific about labeling,for
	example we want to allow the apache process to only read ~/public_html.
	If we are using nfs we need to allow the apache process label httpd_t,
	full access to nfs_t.  Where as if we had labeling of nfs, we could
	label ~/ as user_home_dir_t and ~/public_html as httpd_sys_content_t.
	Then we could allow httpd_t to search through user_home_dir_t and read
	httpd_sys_content_t, just like we do when the homedir is on an ext file
	system or any file system that supports extended attributes.

	We realize in the future we will have to worry about enforcement of the
	labeling at both the server and client side, but for now we just want to
	get extended attributes support in nfs. This would allow us to do client
	enforcement.   If the server supports SELinux we could also do server
	side protections, against labels being put down that the kernel does not
	understand.

	The final advanced protocol that people like the NSA would like would be
	for the server to understand the label of the processes interacting with
	the file, so it could make a policy decision. But this is Far Far down
	the list of my priorities, and I hestitate to mention it since it
	derails my number one goal of just getting NFS to support Xtended
	attributes."

        EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 14 Apr 2011 10:02:28 -0500

On Apr 13, 2011, at 10:55 AM, sfaibish wrote:

> On Mon, 11 Apr 2011 11:09:09 -0400, Thomas Haynes <[email-masked]> wrote:
>> 

I'd still like to start at a high level on stuff.

I'll be sending out the final agenda soon.

---

From: <[email-masked]>
Date: Thu, 14 Apr 2011 08:46:40 -0400

David Black is editing the use cases I wrote up and will send them out.  I am at another conference this week.

Thank you,
Kathleen

-----Original Message-----
From: Sorin Faibish [mailto:[email-masked]] 
Sent: Thursday, April 14, 2011 8:17 AM
To: Thomas Haynes; [email-masked]
Cc: Moriarty, Kathleen; [email-masked]
Subject: Re: [nfsv4] Labeled NFS - agenda bashing for the first meeting

	These labels look like

        EMC²
where information lives

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 14 Apr 2011 14:26:12 -0400

> 	3. NFS homedir labeling to handle process separation.

I'd add

4. Diskless systems (i.e. nfsroot). Currently, I can take any virtually
any image from my favourite Linux distribution, and apply that to run
over nfsroot. Currently, that causes me to lose the rule set based
access controls that are supposed to constrain my privileged processes.

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 14:01:27 -0500

> access controls that are supposed to constrain my privileged processes.

In diskless scenarios we want to say that the client fully owns all of
the relevant filesystems.  In diskless mode you want the client to
make all access control decisions except for the decision that the
client gets to do that, which the server ought to make instead.

Diskless can be done without labeling, including without RPCSEC_GSSv3.
 The only wrinkle is that the client needs to be able to set the
ownership and ACLs of all objects in the writable filesystems that it
owns, but the protocol already provides a way by which the client can
do this even when acting as "root" (I'm referring to ACL-on-create).
The client also needs to be able to set object labels in such
filesystems at will, subject only to server-side label range/set
constraints.

But yes, LNFS would help, even if marginally, in the diskless scenario.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 14:50:55 -0500

Also, the fundamental problem with diskless is that the client needs
to store user/group IDs that the server might not understand.
Stringified UIDs and GIDs will work when the server is willing to
store those, but this will work only for POSIX diskless clients (we
don't have any Windows NFS diskless clients yet, but who knows what
the future will bring).

My vision of NFSv4 diskless clients w/o labeling is as follows:

 - on the server you can set an owner client host principal name on
filesystems owned by that client
 - the server allows that principal full access to the filesystems it
owns, except for write access to read-only filesystems (of course)
 - on the client you store the client host principal name and
credentials somewhere locally
 - the client uses RPCSEC_GSSv1 when accessing the filesystems it
owns, and always with the client host principal as the client
principal
 - the client uses ACL-on-create whenever it creates objects on
filesystems it owns
 - the client uses stringified UIDs and GIDs when dealing with
filesystems it owns

Labels barely enter that picture, though the server could just map the
client principal name to a subject label and treat the entire
filesystem as having the same label, and the server could also enforce
per-object label policies.  It's just that LNFS is not an enabler for
diskless.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 14 Apr 2011 18:11:10 -0400

> don't have any Windows NFS diskless clients yet, but who knows what

I'm expecting most diskless NFSv4 clients to use AUTH_SYS and hence
stringified numerical uids/gids. That's exactly why we clarified that
point in RFC3530bis.

> per-object label policies.  It's just that LNFS is not an enabler for

I didn't say it was an enabler for diskless. I said it is an enabler for
diskless with selinux.

Even if you are running NFS using AUTH_SYS on your local network, a case
can be made for role based access control in order to contain the damage
that can be done by a privileged process which needs to talk to the
outside world through your firewall (e.g. sendmail, ntp, ...) and that
can therefore be subject to attack.

ACLs don't solve that problem nearly as well, because they only work to
allow/disallow access to a file or directory.
Role based security models like selinux and smack go much further in
that you can define a policy that disallows access to specific
operations that your role does not require (e.g. creating a new socket
and/or attaching to a particular port, forking new processes, calling
setuid, ...).

Feel free to envision something different, but the fact that Red Hat and
Fedora have seen enough value to invest in doing  all this work for
disk-based Linux systems seems to me to be a powerful argument for
enabling it for the diskless systems too.

NetApp