Subject: [nfsv4] [LNFS] READDIR filtering based on label

From: David Quigley <[email-masked]>
Date: Thu, 12 May 2011 22:42:12 -0400

I know I was part of writing the original requirements document but
I'm having doubts on whether or not filtering based on labels for
readdir is a good idea. I spoke with Steve Smalley today after our
meeting about this and he brought up several good points. One of them is
that the infrastructure needed to support the READDIR filtering properly
is way more than NFS should be taking on. For example if you filter out
myTSDocument.txt what happens if someone creates myTSDocument.txt? This
is traditionally handled by multi-level directories which we aren't
going to be implementing. The simple point to take out of this is that
you can't deny the creation of it because it leaks just as much
information as having the name there in the first place but we aren't
going to do MLS directories. Traditionally from what I've been told
filenames have been handled MAC policy wise as being contents of the
directory. If you want to hide the fact that there is a file called
elbonia.txt you would move it into a subdirectory and mark that
directory TS. Another major point is that at least in the Linux
community there will be major push back for this feature. We tried it
before when we wanted to do a multi-level proc and there were numerous
technical and philosophical reasons stated why it was not a good idea. I
propose we drop the requirement all together for the filtering/namespace
access part of the draft. It seems that I don't have any customers that
would need this and one might argue that the customers I have are more
likely to be the driving force behind this feature. If someone else has
a real world customer that wants this for another reason than I'm fine
with it but from a MAC security perspective I think we can do without
having this in the draft.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 12 May 2011 22:06:05 -0500

That is a policy decision and exactly why we want to push it off to
the security system to handle.

Assume we have a simple MLS schema and we have two different
implementations: LFS Alpha and LFS Beta.

We have a directory with the following entries and labels:

foo.c (TS)
bar.c (S)
heard.h (U)
gulp.c (TS)
big.c (S)
whoa (U)
    there.pl (U)
    now.pl (S)

Alpha has a policy that an entry is only shown if the S >= O.

Beta has a policy that it returns NFS4ERR_ACCESS if O < S.

So a READDIR under the two policies would show for S == (S)

Alpha:

total 0
drwxr-xr-x   3 thomas  staff   272 May 12 21:59 .
drwxr-xr-x+ 31 thomas  staff  3434 May 12 21:58 ..
-rw-r--r--   1 thomas  staff    60 May 12 21:59 bar.c
-rw-r--r--   1 thomas  staff    70 May 12 21:59 big.c
-rw-r--r--   1 thomas  staff    80 May 12 21:59 heard.h
drwxr-xr-x   2 thomas  staff   136 May 12 21:59 whoa

Beta:

total 0
drwxr-xr-x   3 thomas  staff   272 May 12 21:59 .
drwxr-xr-x+ 31 thomas  staff  3434 May 12 21:58 ..
-rw-r--r--   1 thomas  staff    60 May 12 21:59 bar.c
-rw-r--r--   1 thomas  staff    70 May 12 21:59 big.c
----------   1 nobody  nobody     0 May 12 21:59 foo.c
----------   1 nobody  nobody     0 May 12 21:59 gulp.c
-rw-r--r--   1 thomas  staff    80 May 12 21:59 heard.h
drwxr-xr-x   2 thomas  staff   136 May 12 21:59 whoa

Your scenario sounds like Beta. Someone else might want to do Alpha. And 
they
would have to handle the cases you identified.

---

From: David Quigley <[email-masked]>
Date: Thu, 12 May 2011 23:18:39 -0400

On Thu, 12 May 2011 22:06:05 -0500, Tom Haynes wrote: 

> That is a
policy decision and exactly why we want to push it off to
> We have a
directory with the following entries and labels:
> bar.c
(S)
now.pl (S)
> 
> Alpha has a policy that an entry is only shown if the S
>= O.
> 

> Your scenario sounds like
Beta. Someone else might want to do Alpha. And 
> would have to
handle the cases you identified.

I think the situation is more along
the lines of you would put foo.c and golp.c in a directory called bar
and mark that directory ts. Also its not clear to me if getattr is
governed by the same policy as actual reads and writes. I'm not familiar
with MLS policy enough to be able to definitively say that getattr on an
object and read use same permissions. I can try to find out more about
that tomorrow.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 12 May 2011 22:36:10 -0500

On 5/12/11 10:18 PM, David Quigley wrote:
>
> I think the situation is more along the lines of you would put foo.c 
> and golp.c in a directory called bar and mark that directory ts.
>

That is all an implementation issue. The point is that all filtering is 
under
control of the security system.

> Also its not clear to me if getattr is governed by the same policy as 
> actual reads and writes. I'm not familiar with MLS policy enough to be 
> able to definitively say that getattr on an object and read use same 
> permissions. I can try to find out more about that tomorrow.
>

A smart server needs to check on every NFSv4 operation whether it
is allowed by the security system or not. Note that this may translate
to a check whenever the cfh is modified, but this is the basic model.

But the choice of whether to use the same permissions on a getattr
and a read would be part of the DOI.

Most of LNFS comes down to:

1) Is the subject allowed access to the object?
2) If not, is the subject allowed to know the object exists?

READDIR and LOOKUP are special in the sense that they expose the object
in the namespace.

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 12 May 2011 20:43:40 -0700

On 05/12/11 07:42 PM, David Quigley wrote:
> meeting about this and he brought up several good points. One of them 
> is that the infrastructure needed to support the READDIR filtering 
> properly is way more than NFS should be taking on. For example if you 
> filter out myTSDocument.txt what happens if someone creates 
> myTSDocument.txt? This is traditionally handled by multi-level 
> directories which we aren't going to be implementing.
>

I don't think we want to make it mandatory to support multilevel 
directories. But we should not prevent people from implementing it 
either. Multilevel directories have been supported on many traditional 
MLS systems, and I believe MLS system users understand it and continue 
to expect that feature.

The text in spec need not use words like "filtering" or "multilevel 
directory". I thought we agreed on something like "MAC policy may alter 
results of readdir operation".

- Jarrett

> The simple point to take out of this is that you can't deny the 
> creation of it because it leaks just as much information as having the 
> name there in the first place but we aren't going to do MLS 
> directories. Traditionally from what I've been told filenames have 
> been handled MAC policy wise as being contents of the directory. If 
> you want to hide the fact that there is a file called elbonia.txt you 
> would move it into a subdirectory and mark that directory TS. Another 
> major point is that at least in the Linux community there will be 
> major push back for this feature. We tried it before when we wanted to 
> do a multi-level proc and there were numerous technical and 
> philosophical reasons stated why it was not a good idea. I propose we 
> drop the requirement all together for the filtering/namespace access 
> part of the draft. It seems that I don't have any customers that would 
> need this and one might argue that the customers I have are more 
> likely to be the driving force behind this feature. If someone else 
> has a real world customer that wants this for another reason than I'm 
> fine with it but from a MAC security perspective I think we can do 
> without having this in the draft.
>

Again, the multilevel directory feature on MLS MAC systems has been 
there for a long time. It's hard to gauge the impact of dropping this 
feature. It's a MAC feature, and I am not surprised many people object 
to putting such things in a very general purpose system. MAC system 
users will always be in minority.

- Jarrett

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

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 12 May 2011 21:10:07 -0700

On 05/12/11 08:18 PM, David Quigley wrote:
>> Alpha has a policy that an entry is only shown if the S>= O.
>>
>> Beta has a policy that it returns NFS4ERR_ACCESS if O<  S.
>>
or move it to a file system only holds TS files, or to a TS system all 
together? ;-) When one does a read dir on parent directory of bar, is 
bar shown? If not, what if someone wants to create bar? If your MAC 
model won't support multilevel files or directories, that's fine. One 
can see the file but can't access it. It may be good enough for some 
users. I believe MLS provides better protection in this case -- if one 
is not cleared to see something, one won't even know it exists. It'd be 
harder to hack something that doesn't appear to exist.

> permissions. I can try to find out more about that tomorrow.

I believe they are. If one is not cleared to read/write a file, he/she 
should not be allowed to get attributes of the file either.

- Jarrett

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 May 2011 00:12:12 -0500

On Thu, May 12, 2011 at 10:43 PM, [email-masked]
<[email-masked]> wrote:
> directories. But we should not prevent people from implementing it either.
> Multilevel directories have been supported on many traditional MLS systems,
> and I believe MLS system users understand it and continue to expect that
> feature.

+1.  READDIR filtering is mostly[*] not a protocol feature.  It is
mostly a local, server-side feature.

[*]  READDIR filtering will affect multi-level clients in that they
must not assume that a directory listing obtained under one label will
be valid when accessed -via the local cache- under another label.  It
might be desirable for clients to know whether the server can do any
filtering (though not whether it does in any one case).

So, what I think we need is: a) a filesystem attribute by which the
server can signal that it _can_ do READDIR filtering, b) text advising
clients to not share cached directory listings with processes running
at different levels.  I'd settle for just (b), but I suspect that
client implementors will want (a) as well, so that they can make
better use of local memory resources when the server positively does
no READDIR filtering.  Alternatively, the DOI policy can indicate
whether READDIR filtering may be done, in which case we don't need any
protocol elements.

Nico
--

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 12 May 2011 23:49:05 -0700

> whether READDIR filtering may be done, in which case we don't need any

All the readdir filtering or multilevel directory (or lack thereof) are 
really
built into certain MAC models. So I believe it's reasonable to have the
behavior implied by chosen DOI.

- Jarrett

---

From: Jarrett Lu <[email-masked]>
Date: Fri, 13 May 2011 08:21:53 -0700

On 05/13/11 07:55 AM, McDonald, Alex wrote:
> Complete n00b on the mailing list, apologies for butting in. I just
> wanted to add my 2 cents to this.
>
> The question is (as Tom Haynes noted in one of his posts).
>
> There's a potential security fly in the ointment by allowing (2) if the
> answer to question (1) is a No.
>
> Assume a file called seekrit-stuff with the contents "presidents
> password is WhiteHouse" with a security level of SL(high). Then a
> process at SL(high) could read seekrit-stuff and create a copy of the
> file with security at SL(high). No problem there; perfectly legit.
>
> But what if this process created it with the filename
> presidents-password-is-WhiteHouse? Now any and all processes at SL(low)
> have the contents from the directory listing.

This is not allowed in the MLS MAC model I know. A subject can only
create files at its label, not at any other label. Otherwise, you 
essentially
allow it to downgrade the file label. It can read file whose label it 
dominate.

> In other words, either you don't allow (2) or you MUST implement
> partitioned/multilevel directories.

Multilevel directories is one way to disallow (2).

- Jarrett

> Cheers.

---

From: "McDonald, Alex" <[email-masked]>
Date: Fri, 13 May 2011 15:55:28 +0100

Cheers.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, 13 May, 2011 07:49
To: Nico Williams
Cc: [email-masked]
Subject: Re: [nfsv4] [LNFS] READDIR filtering based on label

>> directories. But we should not prevent people from implementing it
either.

- Jarrett

---

From: "McDonald, Alex" <[email-masked]>
Date: Mon, 16 May 2011 12:25:57 +0100

> From: Jarrett Lu [mailto:[email-masked]]
> Sent: Friday, 13 May, 2011 16:22
> To: McDonald, Alex
> Cc: [email-masked]

Which is the case shown; there's no downgrade. But any process can get
the *filenames* of files it doesn't dominate if the answer to 2 (If not
allowed access, is the subject allowed to know the object exists?) is
"yes". True, it can't do anything with these files, but it doesn't need
to, since the malicious process that has valid access has made the
content available through the publically available filename, without
downgrading. Simply being able to see the filename via READDIR or LOOKUP
from a less secure process provides the potential for exposure of the
contents. 

> Multilevel directories is one way to disallow (2).

I'm suggesting that, without something like multilevel directory
support, it's a security issue if READDIR and LOOKUP do no filtering and
expose all names in the namespace.

---

From: Nico Williams <[email-masked]>
Date: Mon, 16 May 2011 11:38:55 -0500

> expose all names in the namespace.

I agree, but I also think we shouldn't require READDIR filtering.  Let
the marketplace decide how serious a problem this is.

Note that some implementations already have what they need in order to
do READDIR filtering because of share ACLs.  So this is hardly
terribly difficult on the server side.

The client side is more complex because the client can't share the
directory cache as freely, locally, as it might have otherwise.  This
means we need to have some text in the spec about this, but no
protocol elements (since the client will know whether READDIR
filtering may happen because of the LFSes being used).

Nico
--

---

From: Stephen Smalley <[email-masked]>
Date: Mon, 16 May 2011 12:45:49 -0400

> have the contents from the directory listing.

What is the level of the directory in which the new file
"presidents-password-isWhiteHouse" is created?  If the directory is
labeled SL(Low), then the process at SL(high) cannot create the file
there as that would violate MLS "no write down" restriction.  If the
directory is labeled SL(high), then the process at SL(low) cannot read
or search the directory at all, as that would violate the MLS "no read
up" restriction.  Thus, there is no case here where you need filtering
of a directory's contents - just the ability to deny read/lookup
entirely for a given directory.

> partitioned/multilevel directories.

The motivation for partitioned/multilevel directories is typically /tmp
and similar directories where application compatibility requires that
you allow all applications read and write access to a single directory.
It isn't a security requirement but rather a compatibility requirement
that drives multilevel directories.

But note that you can support multilevel directories without the
filesystem implementation being aware of them or directly supporting
them in any way.  This is how it is done in Linux, where the redirection
of processes to per-level /tmp directories is handled entirely through
the VFS support for per-process namespaces and bind mounts; a userspace
component  (pam_namespace) creates the per-level directory if needed and
sets up the bind mount for the process and its descendants.

-- 
Stephen Smalley
National Security Agency

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 16 May 2011 12:04:48 -0500

On May 16, 2011, at 11:38 AM, Nico Williams wrote:

> means we need to have some text in the spec about this,

Why would we need some text in the spec? The client should
already be handling this effect because of the local filesystem
and the same type of scenario.

> but no

What about dumb client and smart server? Assume that the server
looks only at the user to determine the subject label. Joe has TS
and Beth has S.

Joe: ls -la /mnt/documents

Beth: ls -la /mnt/documents

Depending on how close these are issued, Beth could see TS
documents. She might even be able to view the documents if
they are cached.

We don't have a protocol solution for this case.

The answer is to advise either smart clients or for the server
to construct the subject label by machine and not user.

---

From: Nico Williams <[email-masked]>
Date: Mon, 16 May 2011 12:51:54 -0500

> and the same type of scenario.

It'd be an informative note to implementors.  There's no requirement
to have such text in the spec, but if we know this will be an issue,
then it seems polite to tell future readers.

> looks only at the user to determine the subject label. Joe has TS

Dumb clients operate at a single label.  Thus there's no directory
cache sharing issue :)

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 16 May 2011 14:40:03 -0500

> Dumb clients operate at a single label.  Thus there's no directory

FWIW, I recall reading an example much like what I provided earlier.
I can't track it down.

We actually have two different stances on this:

7.3.  Smart Server Mode

   Smart server environments consist of NFSv4 servers that are MAC aware
   and one or more MAC unaware clients.  The server is the only entity
   enforcing policy, and may selectively provide standard NFS services
   to clients based on their authentication credentials and/or
   associated network attributes (e.g., IP address, network interface).
   The level of trust and access extended to a client in this mode is
   configuration-specific.

And

9.7.3.  Smart Server Mode

   In a smart server mode the client behaves as if it were in a normal
   NFSv4 environment.  Since the process on the client does not provide
   a security attribute the server must define a mechanism for labeling
   all requests from a client.  Assume that the server is using the same
   criteria used in the full mode example.  The server sees the request
   as coming from a subnet that is a Secret network.  The server
   determines that all clients on that subnet will have their requests
   labeled with Secret.  Since the directory on the server is labeled
   Top Secret and Secret does not dominate Top Secret the server would
   fail the request with NFS4ERR_ACCESS.

AI: Need to consolidate the above into only 1 section.

I can read 7.3 as stating that a server can look at the user to determine
the subject label. Whereas 9.7.3 has no such ambiguity, there is only
one subject label per client.

My only issue with mandating that  the smart server MUST construct
a single label for a client that presents no subject label is that it goes
against everything we have to date about the security system making
the choice about enforcement.

I'd be okay with using SHOULD and then highlighting the issue of
what happens if the subject label can change, i.e., this directory cache
issue.

Just to be clear, ultimately I would accept the MUST, it solves a
nasty issue and is a simplification that is sound.

---

From: Jarrett Lu <[email-masked]>
Date: Mon, 16 May 2011 12:53:01 -0700

> from a less secure process provides the potential for exposure of the
I understand your argument in favor of having filter function or 
multilevel directories. It's a bit unfortunate that your example of 
creating the scenario that will benefit from multilevel directory is not 
practical (as Stephen explained in his reply). If the file named 
"presidents password is WhiteHouse" can't be created (at SL) by the SH 
subject in the first place, how does read dir or lookup show it?

- Jarrett

---

From: Nico Williams <[email-masked]>
Date: Mon, 16 May 2011 15:14:55 -0500

On Mon, May 16, 2011 at 2:40 PM, Thomas Haynes <[email-masked]> wrote:
> [...]

I don't see that "goes against everything..." conclusion.  Can you elaborate?

We may have discussed treating different users on the same client as
being at possibly different labels, but that's not the same as
agreeing that that's what we want.  Not that this matters -- see
below.

> what happens if the subject label can change, i.e., this directory cache

Well, isn't that what I said?  Note the problem and move on.  Oh,
you're proposing a normative SHOULD whereas I proposed
informative-only text?  Sure, minor difference.

> nasty issue and is a simplification that is sound.

If you want to make this complicated enough you could add that smart
servers MUST treat dumb clients as being at a single label except for
such clients where the server knows they get the cache non-sharing
issue right, in which case the server would be free to derive a
subject label from each user credential.  To me this is all security
considerations text.

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 16 May 2011 20:10:58 -0500

> AI: Need to consolidate the above into only 1 section.

Actually, in trying to consolidate these two sections, I've come to
see why they are different and why they are not contradictory.

7.3 is talking about a general model of a security system whereas
9.7.3 is specifically talking about a MLS enforcement. And that means
that the DOI is responsible for determining what subject label to
assign when one is not presented.

I.e., for MLS, the DOI MUST make sure the client only gets
one label.

However, Nico's idea of calling this out in the Security considerations
is still a good idea.

---

From: <[email-masked]>
Date: Tue, 17 May 2011 15:31:31 -0400

Yes, please.  This is definitely input for a security considerations document and not for the protocol specification itself.

	Thanx...

		ps