Project

General

Profile

Bug #24388

FreeNAS server doesn't respect "owner@:C::deny" ACE. "Owner@" always has ability to change permissions

Added by an odos over 3 years ago. Updated about 3 years ago.

Status:
Closed: Behaves correctly
Priority:
No priority
Assignee:
John Hixson
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

In FreeBSD, owner@ always has "write_acl" and "write_attributes" even if he's explicitly not granted them. For instance, permissions are set to:

owner@:r-----a-R-c---:-------:allow

A/K/A "read_set":allow, the owner of a file / folder can execute the following command to grant himself full control over the dataset.

setfacl -m owner@:full_set::allow foo

This makes sense as an anti-lockout measure to prevent admins from doing stupid things, but it also can lead to privilege escalation in Samba shares where we're using ACLs. Consider the following situation:

  • There are two groups of users "Workers" and "Marketing".
  • Sally is a member of "Workers" and "Bob" is a member of marketing.
  • Permissions are defined at the root of the samba share to grant Workers "WRITE_SET", Marketing "READ_SET", owner@ (CREATOR-OWNER) "READ_SET", and Domain Admins "FULL_SET"
  • Bob creates a directory "Foo". Since Sally is the owner of "Foo", she can use the windows explorer "security tab" to grant herself "Full Control", then grant marketing "WRITE_SET".

I believe this makes it effectively impossible for administrators to audit permissions on Samba shares that use ACLs. I think this is a side effect of the following in /sys/kern/subr_acl_nfs4.c

      /*
     * File owner is always allowed to read and write the ACL
     * and basic attributes.  This is to prevent a situation
     * where user would change ACL in a way that prevents him
     * from undoing the change.
     */
    if (file_uid == cred->cr_uid)
        access_mask &= ~(ACL_READ_ACL | ACL_WRITE_ACL |
            ACL_READ_ATTRIBUTES | ACL_WRITE_ATTRIBUTES);

I just ate lunch so I'm probably not thinking clearly, but this is a pretty horrible feature in an AD environment using ZFS ACLs. This behavior should at least be configurable.

History

#1 Updated by an odos over 3 years ago

Something is definitely amiss here.

[awalker@rivendell] /mnt/Tank/ACLTest/foo% mkdir bar
[awalker@rivendell] /mnt/Tank/ACLTest/foo% getfacl bar
# file: bar
# owner: awalker
# group: wheel
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow
[awalker@rivendell] /mnt/Tank/ACLTest/foo% setfacl -m owner@:C::deny bar
[awalker@rivendell] /mnt/Tank/ACLTest/foo% getfacl bar
# file: bar
# owner: awalker
# group: wheel
            owner@:-----------C--:-------:deny
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow
[awalker@rivendell] /mnt/Tank/ACLTest/foo% whoami
awalker
[awalker@rivendell] /mnt/Tank/ACLTest/foo% setfacl -x owner@:C::deny bar
[awalker@rivendell] /mnt/Tank/ACLTest/foo% getfacl bar
# file: bar
# owner: awalker
# group: wheel
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow

It is impossible to deny C (write ACL) permissions to owner@. I think this poses a significant security problem on Samba servers using vfs_zfsacl for permissions.

#2 Updated by an odos over 3 years ago

  • Subject changed from OWNER@ always effectively has "FULL_CONTROL" in samba shares to FreeNAS server doesn't respect "owner@:C::deny" ACE. "Owner@" always has ability to change permissions leading to compromise of security config on samba server.

#3 Updated by an odos over 3 years ago

  • File Goats visible - regular user.PNG added
  • File Goats hidden - Domain Admin.PNG added

An example of the way that a user can take advantage of this safety net

Initial permissions:

[root@rivendell] /mnt/Tank/CaseInsensitive# getfacl goat/
# file: goat/
# owner: VLSINC\awalker
# group: VLSINC\domain admins
            owner@:-----------C--:fd-----:deny
group:VLSINC\domain admins:rwxpDdaARWcCos:fd----I:allow
            group@:rwxpDdaARWcCos:fd----I:allow
         everyone@:r-x---a-R-c---:fd----I:allow

The folder's owner is clearly denied write permissions to the directory. Domain admins have inherited "full control" from the root of the dataset. The owner decides it's time to hide his goats. He does this by modifying permissions through Windows Explorer. Now permissions are as follows:

[root@rivendell] /mnt/Tank/CaseInsensitive# getfacl goat/
# file: goat/
# owner: VLSINC\awalker
# group: VLSINC\domain admins
group:VLSINC\awalker:rwxpDdaARWcCo-:fd-----:allow

Now the owner has full control of "goat" and no one else can even see it because in Samba + zfsacl files and folders are only visible if users have permissions to read attributes. In short, there's no way for me to stop users from hiding their goats using ZFS ACLs.

Edit: removed goats

#4 Updated by an odos over 3 years ago

  • File deleted (Goats visible - regular user.PNG)

#5 Updated by an odos over 3 years ago

  • File deleted (Goats hidden - Domain Admin.PNG)

#6 Updated by an odos over 3 years ago

  • Subject changed from FreeNAS server doesn't respect "owner@:C::deny" ACE. "Owner@" always has ability to change permissions leading to compromise of security config on samba server. to FreeNAS server doesn't respect "owner@:C::deny" ACE. "Owner@" always has ability to change permissions

#7 Updated by John Hixson over 3 years ago

  • Assignee changed from Alexander Motin to John Hixson

#8 Updated by John Hixson over 3 years ago

  • Status changed from Unscreened to Screened
  • Target version set to 11.0-U1

#9 Updated by John Hixson over 3 years ago

  • Status changed from Screened to 15

an odos wrote:

An example of the way that a user can take advantage of this safety net

Initial permissions:
[...]

The folder's owner is clearly denied write permissions to the directory. Domain admins have inherited "full control" from the root of the dataset. The owner decides it's time to hide his goats. He does this by modifying permissions through Windows Explorer. Now permissions are as follows:

[...]

Now the owner has full control of "goat" and no one else can even see it because in Samba + zfsacl files and folders are only visible if users have permissions to read attributes. In short, there's no way for me to stop users from hiding their goats using ZFS ACLs.

Edit: removed goats

I'm not actually understanding the "bug" here. Everything described in this ticket is a matter or policy. Yes, by design, the owner cannot be locked out of file/directory. As an administrator, you can access and set whatever policy you want. I've seen a wide variety of methods implemented that keep this from occurring. Usually, a user and/or group ACE is applied to the top level directory that always inherits. Very strict ACE's can be set to keep this from occurring. What exactly are you wanting/asking for here? ;-)

#10 Updated by an odos over 3 years ago

John Hixson wrote:

I'm not actually understanding the "bug" here. Everything described in this ticket is a matter or policy. Yes, by design, the owner cannot be locked out of file/directory. As an administrator, you can access and set whatever policy you want. I've seen a wide variety of methods implemented that keep this from occurring. Usually, a user and/or group ACE is applied to the top level directory that always inherits.

Actually, the ZFS ACEs don't stop this from happening. That's the problem. I set explicit "deny" ACEs that the user removed. That said, I realize it's a matter of policy as well. After posting the bug report, I carefully read the NFSv4 RFCs and determined that the FreeBSD implementation is annoyingly correct. :-)

Very strict ACE's can be set to keep this from occurring.

Only if the ACEs are set on the share itself (i.e. in share_info.tdb through sharesec or computer management), which I later realized and adjusted the server configuration.

What exactly are you wanting/asking for here? ;-)

Honestly, I asked myself that shortly after posting the bug report. Did you know that we can't close things we report? I looked for a way to do that, but couldn't find one. So... perhaps a way to close my own tickets and cloud to yell at :-)

#11 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

  • Status changed from 15 to Closed: Behaves correctly
  • Target version changed from 11.0-U1 to N/A

#12 Updated by Dru Lavigne about 3 years ago

  • Private changed from Yes to No

Also available in: Atom PDF