Project

General

Profile

Actions

Bug #1469

open

Hammer history security concern

Added by corecode over 15 years ago. Updated over 3 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
VFS subsystem
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

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.

cheers
simon

Actions #1

Updated by wbh over 15 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.

cheers
simon

Likewise conventional tape archives - hence an admin issue more than
architectural - and by no means a situation unique to Hammer [1].

However:

- 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
owners....

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
they go...

Best,

Bill Hacker

[1] 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....

;-)

Actions #2

Updated by tuxillo almost 11 years ago

  • Description updated (diff)
  • Category set to VFS subsystem
  • Assignee changed from 0 to tuxillo
  • Target version set to 3.8

Grab.

Actions #3

Updated by tuxillo almost 11 years ago

  • Status changed from New to In Progress

Hi,

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.

  1. id antonioh
    uid=1000(antonioh) gid=1000(antonioh) groups=1000(antonioh), 1002(developers)
  2. ls l mydir/secret.txt
    -rw-rw---
    1 root developers 13 Feb 24 01:32 mydir/secret.txt
  3. chown root:wheel mydir/secret.txt
  4. ls l mydir/secret.txt
    -rw-rw---
    1 root wheel 13 Feb 24 01:32 mydir/secret.txt
  5. 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
    mysecretpass
    $ 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.

Cheers,
Antonio Huete

Actions #4

Updated by tuxillo over 3 years ago

  • Target version changed from 3.8 to 6.0
Actions

Also available in: Atom PDF