Hammer history security concern
|Status:||In Progress||Start date:|
Hammer history mounts allow access to deleted files.
This can be an issue if you realized that this data should not have been
available in the first place.
An alternate scenario is that group membership changed, and you don't
want the new group members to have access to past data.
I think we should address this in some sort in the release. One way is
to only allow the owner to access the snapshot, and ignore group/other
permissions on snapshots. This is probably very inconvenient,
especially for root owned system directories.
Another way would be to somehow combine current and past owner/flags,
but this is probably hard to reason about.
#1 Updated by wbh about 5 years ago
Simon 'corecode' Schubert wrote:
> Hammer history mounts allow access to deleted files.
> This can be an issue if you realized that this data should not have been
> available in the first place.
> An alternate scenario is that group membership changed, and you don't
> want the new group members to have access to past data.
> I think we should address this in some sort in the release. One way is
> to only allow the owner to access the snapshot, and ignore group/other
> permissions on snapshots. This is probably very inconvenient,
> especially for root owned system directories.
> Another way would be to somehow combine current and past owner/flags,
> but this is probably hard to reason about.
Likewise conventional tape archives - hence an admin issue more than
architectural - and by no means a situation unique to Hammer .
- given the manner in which Hammer operates, 'obliterate' style delete with
multiple randomized overwrite at the relevant physical media storage locations
wouldn't seem to get the job done, and/or could be highly impractical to apply
over multi-generation history - most especially where networked / remote /
removable media is involved - and is not under the thumb of [one of] the file
In this respect, Hammer is a bit like the proverbial 'cautious' government clerk
told to destroy certain files:
Naturally, he made a copy of each before burning, just to cover his a** ....
Sounds like a utility [ set] is needed?
ELSE - as always - end-lusers warned to privately encrypt their valuables as
 *Any* storage media, especially incremental or 'layered' ones - sedimentary
rock for example - is a potential source of recovery of historical information
that the original owner might have wished kept private.
Think of the embarassment of the dinosaur outed 135 million years on ....as
having been stupid enough to have mis-stepped and suffocated in a mudhole....
- Status changed from New to In Progress
This is absolutely relevant. I am unsure how other filesystems address this.
I've done a little test that illustrates what corecode says.
We have an user that belongs to 'developers' group. In a HAMMER filesystem he is able to access to mydir/secret.txt. Later it's decided that group won't have access to the file anymore but snapshots would still retain the old file attributes and that'd allow this group of users to access the same file from the snapshots.
# id antonioh
uid=1000(antonioh) gid=1000(antonioh) groups=1000(antonioh), 1002(developers)
# ls -l mydir/secret.txt
-rw-rw---- 1 root developers 13 Feb 24 01:32 mydir/secret.txt
# chown root:wheel mydir/secret.txt
# ls -l mydir/secret.txt
-rw-rw---- 1 root wheel 13 Feb 24 01:32 mydir/secret.txt
# su - antonioh
If other operating systems have damaged your Master Boot Record, you can
reinstall it with boot0cfg(8). See "man boot0cfg" for details.
$ cd /mnt
$ cat snap-20140224-0138/mydir/secret.txt
$ cat mydir/secret.txt
cat: mydir/secret.txt: Permission denied
I also think the first proposal of "only allowing owners to access snapshots" is too restrictive. About the second proposal of 'merging' permissions from now/past I am not sure either if that'd be desirable.
It would be very good to know how other filesystems address this.