[nfsv4] POSIX ACLs as backdoor to bypass NFSv4 ACLs Re: Re: Comments for draft-rmacklem-nfsv4-posix-acls-02

[Mark Liam Brown <[e-mail]>]

On Sat, Aug 10, 2024 at 12:35 AM Pali Rohár
<[e-mail]> wrote:
>
> On Wednesday 07 August 2024 08:07:16 David Noveck wrote:
> > On Tue, Aug 6, 2024, 6:21 PM Rick Macklem <[e-mail]> wrote:
> > > On Tue, Aug 6, 2024 at 10:05 AM Pali Rohár <[e-mail]>
> > > wrote:
> > >> 2)
> > >>
> > >> Then there is a problem with "group" bits of "mode" attribute.
> > >> In RFC 8881 section 6.2.4 is written:
> > >>
> > >> "Bits MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP apply to principals
> > >> identified in the owner_group attribute but who are not identified in
> > >> the owner attribute."
> > >>
> > >> And in section 6.3.2.1 is written:
> > >>
> > >> "Some server implementations also add bits permitted to named users and
> > >> groups to the group bits (MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP).
> > >> Implementations are discouraged from doing this."
> > >> "The same user confusion seen when fetching the mode also results if
> > >> setting the mode does not effectively control permissions for the owner,
> > >> group, and other users; this motivates some of the requirements that
> > >> follow."
> > >>
> > >> POSIX ACL with at least one named user or named group requires that
> > >> mode group bits refers to POSIX ACL mask, and not to the POSIX ACL
> > >> group_obj (which represents owner_group).
> > >>
> > >> Those RFC 8881 parts of NFS mode attribute are basically not compatible
> > >> with POSIX ACL. Your extension does not mention this problem and does
> > >> not handle it.
> > >>
> > >> Existing NFS4 servers which follows the RFC 8881 meaning of mode group
> > >> bits, would not be able to implement this your extension for POSIX ACL,
> > >> because existing servers cannot change behavior of mode attribute due
> > >> backward compatibility. I think that this is a big problem.
> > >> Servers in multiprotocol environment mostly follows the RFC 8881 advice
> > >> to never return something like "POSIX mask" in group bits.
> > >>
> > >> How to solve this problem. One option could be including all mode bits
> > >> into your new "posix_access_acl" attribute and let NFS4 clients to use
> > >> only "posix_access_acl" on chown operation, and never use existing
> > >> "mode" attribute at all (if the extension is supported by server).
> > >>
> > >> Another option could be to introduce a new "posix_mode" attribute which
> > >> would be strictly POSIX and old "mode" attribute can stay as before for
> > >> backward compatibility. Again clients would not use "mode" attribute
> > >> anymore.
> > >>
> > >
> > A similar possibility is discussed in an appendix to acls-04.   The idea is
> > a read-only mode_info attribute
> > that clients could use if they want to display a mode that can be displayed
> > to reflect a summary of the ACL permissions.
>
> I think that it should be the client who compose summary of the ACL
> permissions. Why? Because POSIX ACL clients compute this summary
> differently than NFS4 servers who follows RFC 8881 recommendation (to
> not add bits from named users and named group to mode group bits).
>
> So if you have a POSIX ACL compatible system, then its NFS4 should
> report different mode to applications, than the NFS4 compatible system
> which does not support POSIX ACL.
>
> For example if you have POSIX compatible system which connects to two
> different NFS4 servers, where first is POSIX ACL, second is NFS4 ACL and
> you set same access control on both of them for some files (just with
> simple ALLOW cases, which is supported by both POSIX and NFS4 ACL
> models) then every server will report different mode. Even it both
> servers will provide same access. And this is strange.

This is not strange. This is a setup for privilege escalation and data theft.
For example if a file is - per NFSv4 ACL - "append, but not write",
and then you stomp over that with setfacl and give POSIX ACL "write"
rights, then from a NFSv4 ACL point you suddenly have "append AND
write" rights.

Given that bank account transaction files are intentional "append, but
not write" the use of POSIX ACL on such a file would negate all
security, and allows anyone to modify transaction files in random
locations, instead of just adding another transaction.
I'm pretty sure the admins from Goldman Sachs and Deutsche will "love"
such a backdoor feature.

Mark
-- 
IT Infrastructure Consultant
Windows, Linux