Re: subvols and parents - how?

[Axel Burri <axel@tty0.ch>]

On 2015-11-27 03:02, Duncan wrote:
>>> Then there's the security angle to consider.  With the (basically,
>>> possibly modified as I suggested) flat layout, mounting something
>>> doesn't automatically give people in-tree access to nested subvolumes
>>> (subject to normal file permissions, of course), like nested layout
>>> does.  And with (possibly modified) flat layout, the whole subvolume
>>> tree doesn't need to be mounted all the time either, only when you're
>>> actually working with subvolumes.
> 
>> Uhm, I don't get the big security advantage here... whether nested or
>> manually mounted to a subdir,... if the permissions are insecure I'll
>> have a problem... if they're secure, than not.
> 
> Consider a setuid-root binary with a recently publicized but patched on 
> your system vuln.  But if you have root snapshots from before the patch 
> and those snapshots are nested below root, then they're always 
> accessible.  If the path to the vulnerable setuid is as user accessible 
> as it likely was in its original location, then anyone with login access 
> to the system is likely to be able to run it from the snapshot... and 
> will be able to get root due to the vuln.
> 
> On a flat layout, a snapshot with the vuln would have to be mounted 
> before it could be accessed, as otherwise it'd be outside the mounted 
> tree.

Talking about security: If you split the "var" parts from the root, you
get a nice side-effect that the generation of the root subvolume does
not change until you update your system (e.g. by installing/updating
packages).

Consider this setup:

5
|
+--root (subvol)
|  |
|  +--var (subvol, or mounted)
|  +--tmp (subvol, or tmpfs)
|  +--run (subvol, or tmpfs)
|  +--home (subvol, or mounted)
|
+--snapshots (dir, uid=root,mode=700)
   |
   +--root.20150101
   +--root.20150102
   +--...

Now if you take a look at the output of "btrfs sub list -c /", you can
see exactly when your root subvolume has changed. This means if you
always create a new snapshot of "root" after you update your system, you
are able to spot changes to the system easily:

# btrfs sub list -c /
ID 100 gen 4242 cgen 50 top level 5 path root
ID 101 gen 4500 cgen 53 top level 5 path var
[...]
ID 5000 gen 4111 cgen 4111 top level 5 path snapshots/root.20151203
ID 5001 gen 4242 cgen 4242 top level 5 path snapshots/root.20151205
[...]

In this example, I can see that "root" has not been altered since
20151205, as "cgen" of the snapshot matches the "gen" of the root
subvolume. This is the last time I updated this system. If the "gen" of
the root subvolume would be greater than 4242, I know some changes were
made to the system root, and I can start tracking it down using "btrfs
subvol find-new".