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
r, it can read the dir contents correctly. Take
aaway6, 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:allowACL (and nothing else). The unprivileged account can see all the subdirs/subfiles it contains using
lsfrom 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
raccess, then they can be seen within their parent dir listing, even though the
rproperty to view a dir contents should only be needed on the parent. Take
raway 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
cand 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
cACEs 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
aon 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.