Windows 用户可以覆盖 CIFS/SMB 共享上的文件的 NFSv4/Solaris ACL 权限(授予自己完全访问权限),我该如何防止这种情况?

Windows 用户可以覆盖 CIFS/SMB 共享上的文件的 NFSv4/Solaris ACL 权限(授予自己完全访问权限),我该如何防止这种情况?

我在 OmniOS 服务器上设置了 SMB/CIFS 文件共享,并使用 Solaris 内核模块,该模块使用 NFSv4 ACL,应该可以与 Windows 客户端正常配合使用。

我想创建一个共享目录,其目标如下:用户(假设alice)应该能够创建和修改文件,但不能删除它们。还应阻止创建子目录。应允许读取访问。

我已经尝试了以下 ACL,它基本上有效:

/usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share

但如果alice认为安全在 Windows 资源管理器中新添加的文件的选项卡上,她可以授予自己完全访问权限,然后删除该文件,即使她没有Co权限。

如何解释这种行为?我该如何改变它以使 ACL 无法被修改?


编辑:输出ls似乎正常:

# /usr/bin/ls -v
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    0:user:root:read_data/write_data/append_data/read_xattr/write_xattr
        /execute/delete_child/read_attributes/write_attributes/delete
        /read_acl/write_acl/write_owner/synchronize:inherited:allow
    1:user:alice:read_data/write_data/append_data/read_xattr
        /write_xattr/execute/read_attributes/write_attributes/read_acl
        /synchronize:inherited:allow

# /usr/bin/ls -V
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    user:root:rwxpdDaARWcCos:------I:allow
    user:alice:rwxp--aARWc--s:------I:allow

ls目录本身的输出:

# /usr/bin/ls -Vd
drwx------+  3 root     root           4 2016-03-21 .
 user:root:rwxpdDaARWcCos:fd-----:allow
user:alice:rwx---a-R-c--s:-------:allow
user:alice:rwxp--aARWc--s:f-i----:allow

# /usr/bin/ls -vd
drwx------+  3 root     root           4 2016-03-21 .
    0:user:root:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /delete_child/read_attributes/write_attributes/delete/read_acl
        /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
    1:user:alice:list_directory/read_data/add_file/write_data
        /read_xattr/execute/read_attributes/read_acl/synchronize:allow
    2:user:alice:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /read_attributes/write_attributes/read_acl/synchronize
        :file_inherit/inherit_only:allow

共享的文件系统是 ZFS。最有趣的非默认属性如下:

NAME        PROPERTY        VALUE          SOURCE
pool/share  type            filesystem     -
pool/share  compression     lz4            inherited from pool
pool/share  atime           off            local
pool/share  aclmode         restricted     local
pool/share  aclinherit      passthrough    local
pool/share  version         5              -
pool/share  utf8only        on             -
pool/share  normalization   formD          -
pool/share  casesensitivity insensitive    -
pool/share  nbmand          on             local
pool/share  sharesmb        name=testshare local

CIFS 共享权限设置为允许每个人完全访问,因此只应应用文件权限。

更新:

此主题与我的问题非常相似,尽管将 ACL 减少到/pool/share/.zfs/shares/testshare每个modify_set人(或拒绝用户特定的删除权限)的解决方案在我的情况下似乎不起作用,而且我不知道为什么。

答案1

恕我直言,如果你删除用户、组、每个人的简单 acl,一切都会变得非常混乱。需要考虑的事项:

  • 在拒绝权限或缺少文件访问权限的情况下,权限子系统将确定授予文件所有者或超级用户的访问请求。此机制可防止文件所有者被锁定在其文件之外,并使超级用户可以修改文件以进行恢复。
  • 基于 POSIX 草案的 ACL 使用单个条目来定义允许哪些权限以及拒绝哪些权限。新的 ACL 模型有两种类型的 ACE 会影响访问检查:ALLOW 和 DENY
  • 文件所有者被无条件授予 write_acl 权限,即使该权限被明确拒绝。
  • 如果您更改文件的权限,文件的 ACL 也会相应更新。此外,如果您删除授予用户访问文件或目录权限的非简单 ACL,该用户仍然可以访问该文件或目录,因为该文件或目录的权限位授予组或所有人访问权限

因此,我的方法是根据需要修改普通 acl(使用拒绝模式),然后为所有特殊用例添加非普通 acl。请记住这一点:

  • 授予允许权限后,同一 ACL 权限集中的后续 ACL 拒绝条目不能拒绝该权限。

如果不知道 OmniOS 是什么,但这些文档帮助我理解了 NFS ACL。我们使用带有 ZFS 的 Solaris https://docs.oracle.com/cd/E53394_01/html/E54801/ftyxi.html#scrolltoc

答案2

忽略了这个问题一个星期后,它现在突然工作了......我不知道是什么原因造成的,但它工作了......我已经尝试了这个博客,但修改了它以将其AW作为权限。然后我再次测试它,这次只使用我较旧的拒绝规则(完全覆盖新规则),它也起作用了。最后,我使用了我自己的问题中的第一个设置,它从来没有起作用,但现在它们起作用了。

经过更多测试后,我认为这是因为之前未重新启动 SMB 服务,并且共享 ACL 无法正确识别。更改它们是我恢复旧(且错误)行为的唯一方法。

因此,供将来参考,解决方案是在文件本身上定义正常权限,而不允许Co共享级别的权限:

  1. 将以下 ACL 规则应用到目录并(继承)应用到所有新创建的文件:

    /usr/bin/chmod A=\
    user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
    user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
    user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
    /pool/share
    
  2. 将以下 ACL 规则应用于 ZFS 数据集的隐藏共享目录(这是为了防止所有者修改 ACL,有关详细信息,请参阅@embedded 的答案和链接的 serverfault 帖子):

    /usr/bin/chmod A=\
    user:root:full_set:-------:allow,\          # root has full access
    everyone@:modify_set:-------:allow \        # anyone else cannot modify permissions
    /pool/share/.zfs/shares/testshare
    
  3. 重新启动 SMB 服务器(需要更新已更改的共享 ACL,请参阅此主题):

    svcadm restart svc:/network/smb/server:default # restart service
    svcs -xv svc:/network/smb/server:default       # check if the startup date has changed
    

现在可以创建和写入新文件,但不能删除,而且 Windows 用户也不能授予自己额外的权限。此解决方案对我的情况来说很有效,但我看到两个小缺点:

  • 如果将来需要设置额外的权限,您必须记住/记录您更改了共享级别。
  • 用户可能会修改文档的内容。例如,alice可以覆盖文本文档中的字符或行。我认为这是因为我使用的应用程序需要附加和写入权限,并且没有检查“初始只写”或类似权限的 ACL。

相关内容