Subject: [nfsv4] LNFS error codes for MAC access violations

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 25 Apr 2012 17:16:27 +0000

This is based on draft version 08 of the NFSv4.2...

I've got a NFS4ERR_MAC_ACCESS, which I think I intended to use when a
subject label did not match with an object label. However, I seem to
recall some discussion (I.e., I can't track it down in my notes) that we
do not want to return an error code as that informs the client of the
presence of the file system object.

Actually, the current text states:

7.6.1.2:

   When the server receives the request from the client it extracts the
   security attribute conveyed in the RPC request.  The server then uses
   this security attribute and the attribute of the object the client is
   trying to access to make an access control decision.  If the server's
   policy allows this access it will fulfill the client's request,
   otherwise it will return NFS4ERR_ACCESS.

I think this also violates the concern about broadcasting existence based
on error.

1) Are there implementations which may want to return such error codes?
I.e., we might want to do this as a debugging tool.

2) If we don't want to return NFS4ERR_MAC_ACCESS or NFS4ERR_ACCESS, what
do we want to return as an error code?

Would this be a NFS4ERR_BADHANDLE on the PUTFH?

---

From: "Myklebust, Trond" <[email-masked]>
Date: Wed, 25 Apr 2012 18:26:34 +0000

> do we want to return as an error code?

If you really don't want to broadcast existence, then your only option
is to return NFS4ERR_NOENT to a lookup/open/... operation or
NFS4ERR_STALE to a putfh/putrootfh/... operation, and to exclude the
entry from a READDIR.

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Stephen Smalley <[email-masked]>
Date: Wed, 25 Apr 2012 14:33:28 -0400

> Would this be a NFS4ERR_BADHANDLE on the PUTFH?

In Linux with local filesystems, we return an error on a MAC denial and
use the same errno as for a DAC denial (errno EACCES).  Using a
different error code exposes whether it is a DAC or MAC denial, which
could leak information about the DAC attributes if the DAC check happens
first.

File visibility is normally only mediated at the per-directory level,
not at per-file granularity within the same directory.  The exception is
for multi-level directories like /tmp, which has been handled in various
ways by various OSes.  In Linux, it is primarily handled at the VFS
layer by transparently redirecting the process to a per-level instance
of /tmp using per-process namespaces and bind mounts.  No need to hide
the existence of any files there; the process can either see all the
files within a given instance directory or none of them.

-- 
Stephen Smalley
National Security Agency

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Apr 2012 14:36:24 -0500

> Would this be a NFS4ERR_BADHANDLE on the PUTFH?

ENOENT on OPEN.  Filter on READDIR.

Now what if an process at one label passes a file descriptor it opened
to a process running at a label where it could not open that file
itself?  This can't happen in MLS without additional local privileges
to work around MLS, but it can happen in SMACK.  The server can't know
if the client process got the handle legitimately unless the client
process can't possibly have guessed (or learned, via eavesdropping)
the FH.  In this case you might indeed want to return BANDHANDLE or
ACCESS.

Nico
--

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 25 Apr 2012 20:05:01 +0000

Thanks for all of the replies. I'll summarize what I'll change inline:

>presence of the file system object.

I'll remove NFS4ERR_MAC_ACCESS as an error code.

>I think this also violates the concern about broadcasting existence based

There is at least one implementation where the above holds, so it stays.
(This is seLinux.)

>Would this be a NFS4ERR_BADHANDLE on the PUTFH?

This will be server implementation dependent.

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