>> >> Isn't that a gaping security hole? I think this amounts to granting >> >> the backup server root read access (and write access if you want to >> >> restore) on each client? >> > >> > How can you backup system files without root read access? You are >> > granting this to s specific user, one without a login shell, on the >> > server. >> >> If the backup server is infiltrated, the infiltrator would have root >> read access to each of the clients, correct? If the clients push to >> the backup server instead, their access on the server can be >> restricted to the backup directory. > > Yes, but with push you have to secure each machine whereas with pull > backups it's only the server to secure. And you'd still need to grant > access to the server from the clients, which could be escalated. With > backuppc, the server does not need to be accessible from the Internet at > all, all requests are outgoing. If the server machine serves other > purposes and needs to be net-accessible, run the backup server in a > chroot or VM.
I'm planning to rsync --fake-super the important files from each client to a particular folder on the backup server as an unprivileged user and then have the backup server run rdiff-backup locally to maintain a history of those files. authorized_keys on the server would restrict the clients to a particular rsync command in a particular directory. That way if the backup server is infiltrated, the clients aren't exposed in any way, and if a client is infiltrated, the only extra exposure is the rsync'ed copy of the files on the server which isn't a real vulnerability because of the rdiff-backup history. I'd also like to have a secondary backup server pull those same rsync'ed files from the primary backup server and run its own rdiff-backup repository on them. That way all copies of any system's backups are never made vulnerable by the break-in of a single system. Doesn't that compare favorably to a layout like backuppc's? - Grant
