All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: "Martin Schuster (IFKL IT OS DSM CD)"
	<Martin.Schuster1-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [NFS] re-exporting NFS-mounted dir over NFS
Date: Thu, 05 Jun 2008 07:47:35 -0400	[thread overview]
Message-ID: <4847D257.5020406@redhat.com> (raw)
In-Reply-To: <4847871A.5000206-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org>

Martin Schuster (IFKL IT OS DSM CD) wrote:
> Thanks for your thoughts about this.
>
> Peter Staubach wrote:
>   
>> Is the real goal to be able to export the files using krb5
>> authentication or the use of NFSv4?
>>
>>     
> Both, I fear.
>
>   
>> If the former, then why not just export the files from the
>> NetApp using Kerberos?
>>
>> If the latter, then I suspect that it won't provide much, if
>> any, benefit.  It would still be limited to the NFSv3 semantics
>> of the file system.
>>
>>     
> The current NFS4-support in NetApps OnTap is afaik quite new,
> so our filer administrator doesn't want to enable it in the
> near future; he prefers waiting until the issues that are likely
> to come up are solved before allowing it on a productive machine.
>
> But mounting directly from the filer using NFS3+Kerberos would
> allow the following attack vector, as the clients are in an
> unsecure network (i.e. could get root access on their machines):
>  User mounts an directory using his Kerberos-credentials
>  User gets root, then changes w/o password to another user
>  User can now read the files of that other user, as the NFS3-server
>      doesn't check the permissions
>
> (at least, that's how I understood the difference between NFS3
>  and NFS4 -- please correct me if I'm wrong)
>
>   

Ahh, no.  All versions of the NFS servers check permissions on each
and every file access.  Even NFSv2.  NFSv3 and NFSv4 support an
ACCESS protocol operation which allows the client to ask the server
for which file access permissions that the user would be allowed to
have.

When a file system is exported using krb5, then all file accesses
must be made with the right kerberos credential or access will be
denied.  The attack that you described, while working for AUTH_SYS,
does not work for RPCSEC_GSS with krb5, no matter which version of
the NFS protocol that you are using.


> So my question still is: Is re-exporting an NFS-mount technically
> impossible, or does it just need some coding to get it working?

It may be technically possible, in some situations, but is not
something that is always possible or has ever been supported.
It could easily be used to thwart security.  A compromised
client, which was allowed access to file systems from the server,
could then re-export those file systems to other clients which
should not have been allowed access.

----

The bottom line is that 1) I don't think that the NFSv4
implementation from NetApp is as bad as feared and 2) that
using NFSv3 with krb5 should be as secure as NFSv4 with krb5.
Give either or both a shot.  I think that you will be pleasantly
surprised.

       ps

  parent reply	other threads:[~2008-06-05 11:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-04 14:10 [NFS] re-exporting NFS-mounted dir over NFS Martin Schuster (IFKL IT OS DSM CD)
     [not found] ` <4846A272.8040206-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org>
2008-06-04 14:46   ` Peter Staubach
2008-06-05  6:26     ` Martin Schuster (IFKL IT OS DSM CD)
     [not found]       ` <4847871A.5000206-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org>
2008-06-05 11:47         ` Peter Staubach [this message]
2008-06-05 18:33           ` J. Bruce Fields
2008-06-05 16:08         ` Chuck Lever
2008-06-05 18:30   ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4847D257.5020406@redhat.com \
    --to=staubach@redhat.com \
    --cc=Martin.Schuster1-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.