Bug 11658 - Fix for CVE-2015-5299 denies access to ZFS snapshots
Fix for CVE-2015-5299 denies access to ZFS snapshots
Status: ASSIGNED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules
unspecified
All FreeBSD
: P3 regression
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-03 02:42 UTC by QIU Quan
Modified: 2016-05-27 19:02 UTC (History)
11 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description QIU Quan 2016-01-03 02:42:15 UTC
OS platform: FreeBSD 10.1-RELEASE-p25
Filesystem: ZFS
Samba version: upgraded from 4.1.17 to 4.1.22

Problem:

I have been using the shadow_copy2 and zfsacl VFS modules to enable
access control and the Previous Versions feature for Windows clients.
With /usr/local/etc/smb4.conf configured this way (excerpt):

    vfs objects = shadow_copy2 zfsacl
    shadow:snapdir = .zfs/snapshot
    shadow:format = GMT-%Y.%m.%d-%H.%M.%S
    shadow:sort = desc

After updating the package to 4.1.22, which fixes several
vulnerabilities, I discovered that I could no longer view previous
versions of files or folders.

Checking out the log with log level at 10, I found some error
messages, which indicates access to the snapdir, .zfs/snapshots, is
denied.

Error messages:

    ../source3/modules/vfs_zfsacl.c:56(zfs_get_nt_acl_common)
      acl(ACE_GETACLCNT, /tank/share/.zfs/snapshot): Operation is not supported on the filesystem where the file reside
    ../source3/smbd/open.c:128(smbd_check_access_rights)
      smbd_check_access_rights: Could not get acl on /tank/share/.zfs/snapshot: NT_STATUS_NOT_SUPPORTED
    ../source3/modules/vfs_shadow_copy2.c:1170(check_access_snapdir)
      user does not have list permission on snapdir /tank/share/.zfs/snapshot
    ../source3/modules/vfs_shadow_copy2.c:1339(shadow_copy2_get_shadow_copy_data)
      access denied on listing snapdir /tank/share/.zfs/snapshot

Possible fix:

Reading the patch at https://download.samba.org/pub/samba/patches/security/samba-4.1.21-security-2015-12-16.patch,
I see the CVE-2015-5299 fix simply takes the returned status from
smbd_check_access_rights() and only checks if it is OK, and if not,
then fails, also classifying other error statuses as access denied.

Meanwhile, smbd_check_access_rights() in source3/smbd/open.c indeed
returns NT_STATUS_ACCESS_DENIED in some way. I wonder if we change the
line

    if (!NT_STATUS_IS_OK(status)) {

in check_access_snapdir() in source3/modules/vfs_shadow_copy2.c to

    if (status == NT_STATUS_ACCESS_DENIED) {

would result in more accurate outcomes and avoid other statuses such
as NT_STATUS_NOT_SUPPORTED ending up access denied.
Comment 1 Adam Baxter 2016-04-01 07:35:53 UTC
Confirming that this still occurs with FreeBSD 10.3-RC2 and Samba 4.3.3.
Comment 2 anthony.diloreto 2016-04-01 13:29:47 UTC
Sorry I'm new here, but I don't understand how a regression that prevents access to previous versions of files on Windows from ZFS via Samba is at such a low priority.
Comment 3 Richard Sharpe 2016-04-01 16:55:01 UTC
(In reply to QIU Quan from comment #0)

Hmmm, I don't believe that that change is the correct one.

Rather, I think that the problem is that vfs_acl_common (or something) should be falling back to getting perms at that point and converting them to an ACL.

Failing that, smbd_check_access_rights should check Unix perms at that point.
Comment 4 Richard Sharpe 2016-04-01 16:55:55 UTC
I increased the priority a bit so it gets some attention.
Comment 5 Jeremy Allison 2016-04-02 00:08:51 UTC
Why does getting the ACL on the snapshot fail with "not supported" ?

Are ZFS ACLs not supported in snapshot directories ? Why not ?

I need to understand this more thoroughly first.
Comment 6 QIU Quan 2016-04-02 02:51:16 UTC
(In reply to Jeremy Allison from comment #5)

Reasoning from the error message (in bug description), it's the function call to

  acl(name, ACE_GETACLCNT, 0, NULL)

at line 52 in source3/modules/vfs_zfsacl.c, returns ENOSYS, which means the operation is not supported there.

Reference: https://docs.oracle.com/cd/E26502_01/html/E29032/acl-2.html

As I tested with getfacl(1), only at .zfs and .zfs/snapshot acl() looks like not supported, but it is still supported in the subdirectories and files in them.
Comment 7 QIU Quan 2016-04-02 02:56:19 UTC
(In reply to Richard Sharpe from comment #3)

As I tested, unix perms are even not supported on .zfs subdirectories. They don't seem to be real directories, therefore without actual owners and permissions.

root@server:/tank/share/.zfs # ls -l
total 2
dr-xr-xr-x    2 root  wheel    2 Mar 12  2014 shares
dr-xr-xr-x  235 root  wheel  235 Apr  2 10:00 snapshot
root@server:/tank/share/.zfs # chmod 777 snapshot
chmod: snapshot: Operation not supported
Comment 8 Adam Baxter 2016-04-02 04:01:20 UTC
(In reply to QIU Quan from comment #7)
Not quite: 

[voltagex@beastie /BoxODisks/WindowsBackups/.zfs]$ getfacl *
# file: shares
# owner: root
# group: wheel
user::r-x
group::r-x
other::r-x

# file: snapshot
# owner: root
# group: wheel
user::r-x
group::r-x
other::r-x


I'm assuming setfacl would work too, but I don't want to modify this particular dataset.
Comment 9 QIU Quan 2016-04-02 10:56:53 UTC
(In reply to Adam Baxter from comment #8)

Yes, getfacl returns the same result on my box.

However, I would rather argue that getfacl just returns a fake and readonly default acl, the same as my 'ls -l' test does.

I believe your setfacl test would fail the same way as my chmod test.

In fact, the default fake acl would render .zfs/snapshot accessible and traversable by anyone, while the subdirectories, i.e. the snapshots, have the appropriate acl to control access.
Comment 10 pascal.guitierrez 2016-04-05 23:00:47 UTC
This fixes it for me:

--- vfs_shadow_copy2.c.orig     2016-04-05 20:21:53.085935239 +1000
+++ vfs_shadow_copy2.c  2016-04-05 20:23:38.819929670 +1000
@@ -1215,7 +1215,7 @@
                                        &smb_fname,
                                        false,
                                        SEC_DIR_LIST);
-       if (!NT_STATUS_IS_OK(status)) {
+       if (NT_STATUS_EQUAL(status, NT_STATUS_ACCESS_DENIED)) {
                DEBUG(0,("user does not have list permission "
                        "on snapdir %s\n",
                        smb_fname.base_name));
Comment 11 Michael Zoon 2016-04-18 00:05:33 UTC
(In reply to pascal.guitierrez from comment #10)

I can confirm that patch comment #10 also did fix it for me.
Used freebsd 10.3-release amd64 with samba 4.3.8.
Comment 12 Alexander Moisseev 2016-04-18 06:49:48 UTC
(In reply to Michael Zoon from comment #11)
I've applied that patch. There are no errors in the logs anymore, but previous versions still inaccessible. It defenitely worked prior the fix for CVE-2015-5299 with the same configuration.

On Windows 10 only members of the samba server group sid="S-1-5-32-544" (BUILTIN\Administrators) have access to snapshots, for other users Windows 10 doesn't show snapshot list, just message "There are no previous versions available".

WindowsXP shows snapshots for all users, but on "View" button press it throws "access denied" error for privileged users and opens user's profile directory for other users.

FreeBSD 10.3-RELEASE amd64, samba43-4.3.8

    vfs objects = shadow_copy2 zfsacl
    shadow:snapdir = .zfs/snapshot
    shadow:sort = desc
    shadow:localtime = yes
    shadow:format = %Y-%m-%d_%H.%M.%S--36h
Comment 13 Mahmoud Korayem 2016-04-29 19:06:50 UTC
I confirm here too, issue is still there

FreeBSD 10.3-RELEASE (GENERIC) #0 r297264: Fri Mar 25 02:10:02 UTC 2016
Samba 4.3.8
Comment 14 Mahmoud Korayem 2016-04-29 19:39:29 UTC
Just to note:

I tries to add in smb4.conf(This let the users act as root):

admin users = USER1, USER2

Now any user in this list can both see the ACLs in windows security tab and also .zfs/snapshot in Previous Versions
Comment 15 Svitlik Dmitriy 2016-05-01 23:40:02 UTC
Hope this helps.
That config works with 4.3.8 @ FreeBSD 10.2RELEASE:

vfs objects = shadow_copy2 aio_pthread
# zfsacl

but:

vfs objects = shadow_copy2 zfsacl aio_pthread

fails with these lines in messages:

../source3/modules/vfs_shadow_copy2.c:1221(check_access_snapdir)
user does not have list permission on snapdir /$pool/$dataset/.zfs/snapshot
../source3/modules/vfs_shadow_copy2.c:1390(shadow_copy2_get_shadow_copy_data)
access denied on listing snapdir /$pool/$dataset/.zfs/snapshot
../source3/modules/vfs_default.c:1189(vfswrap_fsctl)
FSCTL_GET_SHADOW_COPY_DATA: connectpath /$pool/$dataset, failed - NT_STATUS_ACCESS_DENIED.

.zfs and .zfs/snapshot cannot have any ACL, because it system objects, so acl check fails, I guess.

ACLs for file on share:
~ % getfacl /$pool/$dataset/Zipdll.dll
# file: /$pool/$dataset/Zipdll.dll
# owner: nobody
# group: nogroup
            owner@:rwxp--aARWcCos:------:allow
            group@:r-----a-R-c--s:------:allow
         everyone@:r-----a-R-c--s:------:allow

... and for .zfs (.zfs/snapshot will be the same)
~ % getfacl /$pool/$dataset/.zfs
# file: /$pool/$dataset/.zfs
# owner: root
# group: wheel
user::r-x
group::r-x
other::r-x
Comment 16 QIU Quan 2016-05-11 06:08:24 UTC
(In reply to Jeremy Allison from comment #5)

Trying to find out why getfacl(1) still works for .zfs and .zfs/snapshot, I briefly read the source code of getfacl.c.

In the function print_acl(), where acls are retrieved and printed, it apparently falls back to the stat struct when calling acl_get_file(3) fails, as shown:

https://svnweb.freebsd.org/base/releng/10.1/bin/getfacl/getfacl.c?revision=272461&view=markup#l224

The stat struct gets populated by the first few lines of the function print_acl(), where it calls the stat(2) system call.

So does it make sense if we could let vfs_zfsacl do the same, i.e. falling back to stat(2) when the acl(name, ACE_GETACLCNT, 0, NULL) call returns ENOSYS?

Where should I see if there is an example of assembling samba acls from stat structs?
Comment 17 Jeremy Allison 2016-05-11 11:09:03 UTC
source3/smbd/posix_acls.c has code that will create an ACL from a 3-component stat struct.