To workaround a FreeBSD ACL bug I need to grant "read attributes/ACLs" to untrusted Samba users. Not happy about security - can practical harm result?

Question

I've found either one, or more than one, bug, in ACL evaluation, when running Samba on FreeBSD. I can't be sure if these are facets of the same bug or related bugs - they're very similar but do have distinct features and expose different specific concerns.

I'll give a quick description of the bugs it looks like I've found, first:

ACL bugs reproducible on FreeBSD without Samba

• Bug #1 - an unprivileged account that should be able to read a dir content, and can read it, stops being able to read it (ls:denied) when another account is granted "allow" access in a different ACE.

• Bug #2 - If the unprivileged account is now granted ra instead of r, it can read the dir contents correctly. Take a away6, and it no longer can.

I reported this bug on FreeBSD bugzilla with the details needed for consistent reproduction.

ACL bugs reproducible on FreeBSD using Samba smbclient tool on same server

Using clean/newly created shares and users, so there's no impact from any previous smb.conf setup:

• Bug #3 - subdirs and subfiles are created within a share root, and the share root dir is given everyone@:r:allow ACL (and nothing else). The unprivileged account can see all the subdirs/subfiles it contains using ls from console CLI, but gets "access denied" when trying the same via smbclient CLI.

• Bug #4 - In the same scenario, if the subdirs (emphasis: not the root dir) are given r access, then they can be seen within their parent dir listing, even though the r property to view a dir contents should only be needed on the parent. Take r away from the subdir, and it can't be seen within its parent dir listing.

• Bug #5 - not yet fully figured this one out, but appears consistent. In some cases the unprivileged account can see a dir via console CLI, but cannot see it via smbclient CLI ("access denied"). Setting everyone@:c:allow (view ACLs) right on the directory , it is able to view the dirs. contents. Remove c and it gets "access denied" again.

I haven't reported these yet, because I'm still trying to figure out if I'm looking at one bug, two, samba issues, or FreeBSD issues. I've tentatively asked about the first two (#3 and #4) on Superuser, to get any insights, so there's more detail there.

My security related question from these

I can't fix FreeBSD or Samba, and I need to use ACLs to control the various uses + users of this server, so these look like bugs I have to live with until fixed, unless someone finds (by a miracle) that there's a "known cure" or something.

• I'm not worried about server CLI aspects - I'm the only one using CLI access to the server.
• I'm also not worried about remote iSCSI users, because by definition the remote system (ESXi etc) will set up and manage the file system and any permissions; this server won't "see" any of it anyhow.
• So the main problem is remote samba file share users, and the primary security issue would be related to untrusted accounts accessing the server via Samba. By untrusted I mean friends+family - I trust the users but their laptops or whatever's connecting is assumed to be in an unknown state of security/openness.

My problem is that to get security working properly, it looks like I'll be forced to grant read-attributes, and/or read-ACL rights on shared directories, where I had planned these users never had any need to see ACLs or attributes, so they wouldn't have those rights.

If I have to do this (and it looks like I do), what are the risks and issues, from a security perspective, of being forced to put "a" and/or "c" rights for everyone@ (or for certain untrusted users/groups), on directories where they shouldn't have any need to see these things?

Part of me thinks it's a bit like "security by obscurity" - if the ACLs are there and the system secure, then exposing ACLs can't do harm. Part of me thinks about information leakage - it discloses names and IDs for users+groups, and hints at what is needed to view various directories, and what accounts exist and will open the doors.

How should I assess this problem?

Update - possible mitigating factors

Because the issue is data files exposed via Samba, there are a few other factors which partly reduce any attack surface:

• there aren't any files where any remote user has execute permission/ACLs
• all ACEs are either on "well known groups" such as owner/group/everyone@, or on groups only used within the data pool (none of which have shell or other login rights)
• the extra a and c ACEs needed to list/enter the affected dirs, only need to be on those dirs. Meaning that dirs which don't need to be listable by a user account (they're traversable or not readable) don't need those extra ACEs. Further, they don't need to be on files themselves.
• although it would probably incur a significant performance hit on Samba (check all ACLs on all files when accessing a dir), Samba can be configured to not list files that a user can't access, when it lists a dir. The param is 'hide unreadable'. As a server-side control, the user can't avoid its effect, and if I'm forced to set r or a on a dir, to see one subfile/subdir, at least it doesn't expose names of unauthorised files/dirs - it doesn't prevent exposure of valid user/group names which are used within the data dir, or ACLs from accessible objects, though.
• Samba only faces the LAN (private IPv4), although with family and friends, and the unknown state of their devices, that's not saying much for security.

Are there any mitigations I've missed?

An ideal mitigation would simply prevent clients being told about ACLs regardless - Samba has many overriding functions (override user rights and set as admin user, override owner/ACL inheritance behaviour, etc). But I don't think such a setting exists in smb.conf.

Answer 1

IMHO, I think you have mostly answered your own question.

It is never a good idea to disclose this information, not to mention any other potential Samba exploits (which I think you have already shown to be famously buggy) which may be assisted by knowledge of these attributes.

If it cannot be avoided, you would want to be 100% certain that your ACLs and other potential attack vectors common to the user/group names/IDs and related access controls are watertight. If the risk of intrusion is high enough, you should re-consider if you can avoid using Samba or go to a lot more effort to compensate for this unwanted disclosure.