If the system is set up such that extra copies of all files are created somewhere, for example at /backup/home/bob/online_banking.txt, then the sys admin has to remember to change the permissions for that copy also.
Exactly. Except that, in case of ZFS, these extra copies are made world-readable by force (assuming they had been world-readable by the time the snapshot was taken) and that there is no way to undo this except by destroying the snapshot. But since our snapshot must exist for a non-zero time (e.g. until it has been sent somewhere), there is a window where people may access data, which shouldn't have access to. Hence it's a security flaw.
Of course, you could argue: Don't create snapshots, then the security issue doesn't exist. But that would be like saying: "Don't use
sshd on a server that's exposed to the internet." in order to fix a security hole in
sshd.
Snapshots are
meant to exist for a non-zero time. (Same as
sshd is meant to be exposed to the internet.)
(I'm sorry for saying it that way, but I didn't know how else to phrase this in an understandable way.)
If used correctly, there is no security problem.
The only way to use snapshots correctly (currently) is to either:
- use one ZFS dataset for each user and only give that user access to the respective file system root, or
- not change any privileges on the system (e.g. modify group memberships) while a snapshot exists, or closely monitor whether the changes will have a particular impact in the given scenario.
Unfortunately, the first isn't what most people want (and it's not the default), and the second is not documented right now (at least I didn't find anything in the man pages in that matter).
There
is documentation that the snapshot is mounted, but it is not explicitly mentioned that
- it will be potentially readable by anyone (and this cannot be changed!),
- it may cause security issues if, for example, group memberships change,
- it is necessary to delete snapshots
after (edit) before certain events.
Of course, you could argue that a system administrator should deduce all this by themself, but given the discussion in this forum (and the fact that this issue has been around for years without a fix), I doubt that a huge number of administrators is aware of the issue.
I personally was
shocked (edit) surprised when I discovered this several years ago because I didn't believe anyone would deliberately design it like that. And then I searched for ways to change the behavior, and there was no way.
But even
if it gets documented, then using ZFS snapshots on a multiuser system is still a pain from a security p.o.v. Force mounting the snapshots as world-readable (if the dataset root has been world-readable) is bad practice and requiring the consequential caution from the user of the OS cannot (in my opinion) align with FreeBSD's goals of "taking security very seriously" and "making the operating system as secure as possible". There may be people disagreeing with me here, which is why I'd like to hear an official assessment from the FreeBSD security team on that matter.
I don't understand how creating a dataset per user is more work than having a setting that says part of this snapshot can only be seen by this specific user.
Because I have to create a separate ZFS dataset for each user? Data deduplication also doesn't work across datasets, right? When I move files between datasets, there is extra I/O load, etc.
If you restrict to only root, then as previously hinted, just send all snapshot to a new dataset that only root can access.
While I send the snapshot, the snapshot must exist. Thus the time for which the snapshot exists is non-zero. Sending the snapshot somewhere and then destroying it can lower the risk, but (disregarding the extra effort in some scenarios) it doesn't "fix" the security issue.
. WARNING, do not attempt the following on a productive zpool, it may leave your system in an unwanted state: