Bug 12912 - The #12490 broke NTACL handling/translation on FreeBSD (and AD DC role is broken as a result too)
Summary: The #12490 broke NTACL handling/translation on FreeBSD (and AD DC role is bro...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.6.6
Hardware: All FreeBSD
: P5 major with 1 vote (vote)
Target Milestone: ---
Assignee: Ralph Böhme
QA Contact: Samba QA Contact
: 12730 (view as bug list)
Depends on:
Reported: 2017-07-16 14:30 UTC by Andriy Syrovenko
Modified: 2020-03-02 11:06 UTC (History)
6 users (show)

See Also:

Possible patch for master (2.66 KB, patch)
2017-07-16 15:19 UTC, Ralph Böhme
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Syrovenko 2017-07-16 14:30:29 UTC
The code in lib/replace/xattr.c used to work on FreeBSD as follows:

1. Attribute prefixed with "system." used to be mapped to EXTATTR_NAMESPACE_SYSTEM.
2. Any other attributes used to be mapped to EXTATTR_NAMESPACE_USER.
3. In any case the namespace name prefix used to be stripped.

This was not ideal, but it worked.

Now since #12490 has been "fixed" the code in lib/replace/xattr.c work as follows:

1. Attributes prefixed with "system." are mapped to EXTATTR_NAMESPACE_SYSTEM.
2. Attributes prefixed with "user." are mapped to EXTATTR_NAMESPACE_USER.
3. Any other attributes ARE REJECTED with ENOATTR.

The problem is Samba uses "security.NTACL" to store NTACLs (in addition to mapping them to POSIX ACLs), and this behavior seems to be vital for Samba to work as AD DC. And now this attribute became invalid on FreeBSD. For instance, if you try to provision a new domain, samba-tool will fail with

set_nt_acl_no_snum: fset_nt_acl returned NT_STATUS_INVALID_PARAMETER.
ERROR(runtime): uncaught exception - (-1073741811, 'Unexpected information received')
  File "/usr/local/lib/python2.7/site-packages/samba/netcmd/__init__.py", line 176, in _run
    return self.run(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/samba/netcmd/domain.py", line 471, in run
    nosync=ldap_backend_nosync, ldap_dryrun_mode=ldap_dryrun_mode)
  File "/usr/local/lib/python2.7/site-packages/samba/provision/__init__.py", line 2175, in provision
  File "/usr/local/lib/python2.7/site-packages/samba/provision/__init__.py", line 1806, in provision_fill
    names.domaindn, lp, use_ntvfs)
  File "/usr/local/lib/python2.7/site-packages/samba/provision/__init__.py", line 1593, in setsysvolacl
  File "/usr/local/lib/python2.7/site-packages/samba/ntacls.py", line 162, in setntacl
    smbd.set_nt_acl(file, security.SECINFO_OWNER | security.SECINFO_GROUP | security.SECINFO_DACL | security.SECINFO_SACL, sd, service=service)
Comment 1 Ralph Böhme 2017-07-16 15:19:07 UTC
Created attachment 13391 [details]
Possible patch for master

This should fix it. Can you test?
Comment 2 Andriy Syrovenko 2017-07-17 04:49:26 UTC
(In reply to Ralph Böhme from comment #1)

The patch appears to solve the issue. Thanks.
Comment 3 Andrew Bartlett 2017-07-17 09:31:52 UTC
Comment on attachment 13391 [details]
Possible patch for master

I don't think that is safe.  I think it needs to be mapped to EXTATTR_NAMESPACE_SYSTEM.

The issue is that the attributes are trusted (we can override permissions based on them), so need not to be modified except by root or perhaps the file owner - whatever the Linux semantics are.
Comment 4 Andriy Syrovenko 2017-07-17 09:56:59 UTC
On FreeBSD the EXTATTR_NAMESPACE_SYSTEM namespace has its own problem- this namespace is completely inaccessible from withing a jail. Unfortunately, this is a hardcoded behavior, not something that can be tuned.

We have Samba AD DC running in a jail in production, moving NTACL to EXTATTR_NAMESPACE_SYSTEM will be a serious showstopper for us.
Comment 5 Ralph Böhme 2017-07-17 10:01:41 UTC
(In reply to Andrew Bartlett from comment #3)
That would not be compatible with existing deployments (if there are any) where existing NTACL will be in the user namespace.
Comment 6 Andrew Bartlett 2017-07-17 10:30:22 UTC
I'm not sure that use in a jail (just as use in a docker container) is compatible with the Samba security model.
Comment 8 Andriy Syrovenko 2017-07-17 10:51:41 UTC
(In reply to Andrew Bartlett from comment #6)
What do you think is wrong with Samba in a jail (provided a man setting it up understands how stuff works)?

You do not recommend (for a reason) using a single installation as a DC and as a file server at the same time, so running DC in one jail and file server in another on the same host sounds like a natural approach. Modern computers are too powerful to be only running Samba as DC for a small network of about 100 workstations.

I don't run anything (except ntp and ssh daemons) in the host environment, and both jails are fully isolated one from another. Also I'm using VNET/VIMAGE, which means both jails have their own independent and fully functional network stack.

So, can you please elaborate on what may be wrong with this setup?
Comment 9 Andrew Bartlett 2017-07-20 05:33:27 UTC
(In reply to Andriy Syrovenko from comment #8)
> What do you think is wrong with Samba in a jail 

The lack of access to the system. / EXTATTR_NAMESPACE_SYSTEM namespace is what concerns me.
Comment 10 Andriy Syrovenko 2017-07-20 18:49:06 UTC
(In reply to Andrew Bartlett from comment #9)
OK, I think I now understand your concerns. User attribute data is protected according to the usual discretionary and mandatory protection rules, and that may or may not be a security problem, depending on how a particular system is setup.

On the other hand FreeBSD guys have good reasons to keep system attributes inaccessible from jails. For what I've found, things like POSIX ACLs and MAC labels are stored as system extended attributes, and that is not something that should be accessible from the jail, indeed.

I'd like to suggest a compromise. Can we restore the previous behavior (i.e. map "security." to EXTATTR_NAMESPACE_USER) at least in 4.6.x? For the future versions the ideal solution will be to map "security." to EXTATTR_NAMESPACE_SYSTEM by default, but at the same time make the ACL name (including the namespace part) that is used to store NTACLs configurable.

Meanwhile, I'm going to check if I can use some kind of MAC policy to make NTACL attributes in user namespace be only accessible by root.

Comment 11 Andrew Bartlett 2017-07-26 19:41:13 UTC
*** Bug 12730 has been marked as a duplicate of this bug. ***
Comment 12 Timur Bakeyev 2017-08-17 21:48:17 UTC
(In reply to Andriy Syrovenko from comment #10)

It would be great if FreeBSD could introduce new namespaces. There is no real reason not to be able to, but, possibly, there are legacy concerns.

The way it's implemented now allows to have dozens of new NSs, but seems, besides "system" and "user" NSes there are no conventions on them..
Comment 13 Ralph Böhme 2018-07-07 13:09:15 UTC
Comment 14 Ralph Böhme 2018-07-07 13:11:44 UTC
My fix in bug #12490 broke this, the proposed patch in attachment #13391 [details] simply restores the previous behaviour.

While I understand Andrews security concerns, I don't think that should be intertwined.

Comment 15 Timur Bakeyev 2018-07-07 16:24:00 UTC
(In reply to Ralph Böhme from comment #14)

Meanwhile I wrote a VFS module that takes care of this and introduces other variants of xattr handling. Let me clean it up a bit and send for the review.

With introduction of the ZFS the security.NTACL issue became less important, as everything maps into NFSv4 ACLs.
Comment 16 Andriy Syrovenko 2018-07-07 16:40:20 UTC
(In reply to Timur Bakeyev from comment #15)

Does AD DC embedded FS support NFSv4/ZFS ACLs (for sysvol share) already? It dodn't used to, and that's the main problem. Is your VFS plugin compatible with AD DC embedded FS?
Comment 17 Timur Bakeyev 2018-07-15 23:33:19 UTC
(In reply to Andriy Syrovenko from comment #16)

Well, FreeBSD port does support NFSv4 ACLs on ZFS. Not sure, what do you call 'embedded' FS, possibly - native FreeBSD ones?

Well, Samba ports 4.7 and 4.8 work on ZFS OOTB with altered vfs objects line, on UFS - just as is, with the mapping of NTACL into user.NTACL xattr(which is not secure).

My module supports this behavior, as legacy, for compatibility, also is able to map secure.* xattr into secure.* in the EXTATTR_SYSTEM_NAMESPACE(and can fall back to EXTATTR_USER_NAMESPACE in a jail).

The question now is in transiting xattrs from one name space into another, as my module keeps original xattr prefixes for easier cooperation with Linux. I.e. it keeps prefixes, like user., system., secure., trusted. untouched.