On 2016-09-07 12:10, Graham Cobb wrote:
On 07/09/16 16:20, Austin S. Hemmelgarn wrote:
I should probably add to this that you shouldn't be accepting
send/receive data streams from untrusted sources anyway. While it
probably won't crash your system, it's not intended for use as something
like a network service. If you're sending a subvolume over an untrusted
network, you should be tunneling it through SSH or something similar,
and then using that to provide source verification and data integrity
guarantees, and if you can't trust the system's your running backups
for, then you have bigger issues to deal with.
In my personal case I'm not talking about accepting streams from
untrusted sources (although that is also a perfectly reasonable question
to discuss). My concern is if one of my (well managed and trusted but
never perfect) systems is hacked, can the intruder use that as an entry
to attack others of my systems?
Probably not directly. They could get data from the other systems
backups, but unless something's seriously broken, there should be no way
for them to inject data into those backups. IOW, it should be about the
same level of security you would get from doing this with tar based
backups with an individual user for each system and world readable files.
In particular, I never trust my systems which live on the internet with
automated access to my personal systems (without a human providing
additional passwords/keys) although I do allow some automated accesses
the other way around. I am trying to determine if sharing
btrfs-send-based backups would open a vulnerability.
As far as I can tell, the only vulnerability would be through
information leaks. In essence, this should in theory only be usable as
a side-channel to obtain information to then use for a real attack
(assuming of course that you have proper at-rest encryption for any
sensitive data on your system).
There are articles on the web suggesting that centralised
btrfs-send-based backups are a good idea (using ssh access with separate
keys for each system which automatically invoke btrfs-receive into a
system-specific path). My tests so far suggest that this may not be as
secure as the articles imply.
While just doing that in general is not all that secure, if you make
sure each system-specific path is on it's own filesystem (this can be
done with thin provisioning if you are short on space), then that should
eliminate most of the security issues. If you're feeling really
adventurous and don't entirely trust the stability of the code involved,
you could instead force it to run a script which invokes btrfs-receive
in a per-instance dedicated sandbox constrained to that filesystem.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
