On Wed, 2013-08-07 at 18:24 +0000, Adamson, Andy wrote:
> On Aug 7, 2013, at 2:19 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx>
> wrote:
>
> > On Wed, 2013-08-07 at 14:04 -0400, Trond Myklebust wrote:
> >> On Wed, 2013-08-07 at 18:01 +0000, Adamson, Andy wrote:
> >>>
> >>> Here is the attack as described in 3530bis Security Considerations
> >>> section:
> >>>
> >>>
> >>> The second operation that should definitely use integrity protection
> >>> is any GETATTR for the fs_locations attribute. The attack has two
> >>> steps. First the attacker modifies the unprotected results of some
> >>> operation to return NFS4ERR_MOVED. Second, when the client follows
> >>> up with a GETATTR for the fs_locations attribute, the attacker
> >>> modifies the results to cause the client migrate its traffic to a
> >>> server controlled by the attacker.
> >>
> >> You can the exact same thing by changing the READLINK results.
> >
> > The attack is: change the unprotected LOOKUP results to point to a
> > symlink, then feed '/net/<evil-ip-address>/my/evil/pathname' into
> > READLINK.
> >
> > My point is that if you're on a network where the above is a potential
> > threat, then you should be using krb5i or, better yet, krb5p for _all_
> > operations. It's not sufficient to single out fs_locations for special
> > treatment.
>
> In that case, why did you accept commit 4edaa308 "NFS: Use "krb5i" to establish NFSv4 state whenever possible" ?
1. To avoid the NFS4ERR_CLID_IN_USE problem when you change from
one mount auth flavour to another.
2. In scenarios where mixed security is in use, the state manager
should always use the strongest security. Previously, we just
chose whatever security flavour that was used first.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
