Pull mode documentation: Security: Client is able to run code on server

[pcworld]

Have you checked borgbackup docs, FAQ, and open Github issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

Issue

Your borg version (borg -V).

1.1.16 (current documentation)

---

The pull backup documentation suggests to set up a chroot to back up remote servers.
There is already a security warning that a compromised backup server will be able to "cause unlimited damage to the client".

However, this security issue goes both ways: A compromised client is likely to be able to run arbitrary code as root on the backup server.
For example, a malicious client can replace its own shell binary. This is then run as root on the backup machine in the chroot context. Escaping the chroot is easy, e.g. the client is able to load malicious kernel modules on the backup host via insmod, or use one of the bind-mounted file systems (/dev /proc /sys) to escape the chroot, e.g. by manipulating /dev/mem.

The warning should be expanded that the compromise can work both ways.
Ideally, the chroot solution should be replaced by something more secure.
According to the pull backup documentation, the chroot is just performed so that borg will be able to read /etc/passwd and /etc/group. borg could introduce parameters to specify the path to these files so that chrooting will not be needed.

Further, the FAQ How can I protect against a hacked backup client? suggests that the pull mode documentation "protect[s] against" "the attacker could then use borg on C to delete all backups residing on S". For the reasons outlined above, the chroot solution does not prevent that.

[ThomasWaldmann]

@pcworld thanks for discovering this / notifying us here. could you do a pull request to fix the docs?

about giving pathes to passwd/group to borg: our code currently uses the python standard library functions to deal with user and group names and they can't be told to use a different filename to get that information from:

• pwd.getpwnam
• pwd.getpwuid
• grp.getgrnam
• grp.getgrgid

Also, when thinking about this: the user and group id/name matching can be done in other ways also, not just via these files, so the attempt to use these files via chroot might be futile if another mechanism is used (additionally). See /etc/nssswitch.conf.

[ghost]

I would like to tackle this but a couple of clarifying thoughts first.

You mention it is insecure but the warning says this should only be done on a machine you fully trust. So the threat model already includes that risk.

Secondly, it seems like the chroot method has to do with UID/GID mappings and whether borg uses /etc/passwd or not is an implementation detail (so probably should not be mentioned in the docs anyway due to potential confusion?) I think better advice would be to do backups under a dedicated borg user or something. Using a chroot for UID/GID mappings sounds like an incorrect solution to the problem and as already mentioned doesn't actually provide security.

[ThomasWaldmann]

The docs already says you need to fully trust the backup server.
This ticket adds that you'ld also have to fully trust the (other) machine being backed up due to the chroot approach.

IIRC the whole reason for chroot was that the "correct" UID/GID mapping is used by using the /etc/passwd and /etc/group from the backed up machine (and not the backup server). This only works 100% correctly if that is the only source of uid/gid mappings and nothing else is configured on the backed up machine via nsswitch.conf (e.g. users/groups in ldap).

I think, if we keep that whole "pull and use a chroot" approach in the docs, we need to tell this so people won't mess up their backups with wrong user and group names.

One could also check master branch against 1.1-maint branch: do we have better "pull mode" approaches in master than in 1.1-maint?