From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 70FAF1381F3 for ; Mon, 1 Jul 2013 08:40:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A5FDCE0982; Mon, 1 Jul 2013 08:39:59 +0000 (UTC) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 33AB2E086F for ; Mon, 1 Jul 2013 08:39:57 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b12so3509619wgh.7 for ; Mon, 01 Jul 2013 01:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WLjhAscPzy6KtOv9kYL613myZ5QOiwQ/+rn/If8Y5iM=; b=xIGMYkOn8TVyFBh1I0FpEURlX5p1JUn9WAeK+y4eHb++NGM1keRv6Vi2ELxUCaPQX2 QIYxR2UF22AOelmB/CzxGy5H0yNRUZfkzQwk4Z4T61Su+lbUwn+gg0cD63u0sZwXM1KL ahuw08TkPSLIkvAUX2FDCGLk0XCSJMTZBDOD0OVldhXVWRi/xcA+afoLGB1hB85KsJfT rNYFlIV6oGmLZCbt7ClyWYmIiUw+S15Gq+ROK0benQhle3Ta5sGq1fhV+dC3NSjqC3qe 8ofSFERNPI0KJt0gVi8RmmBrjmLx66ySP/Vg7feaEqIc0SE3a/6EQI547ST7pXbvrssF GZQA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.180.108.129 with SMTP id hk1mr11256303wib.56.1372667996738; Mon, 01 Jul 2013 01:39:56 -0700 (PDT) Received: by 10.194.25.97 with HTTP; Mon, 1 Jul 2013 01:39:56 -0700 (PDT) In-Reply-To: <20130701012918.4f1ed146@digimed.co.uk> References: <20130630085826.64e55fd0@digimed.co.uk> <20130630100510.03d1ea62@digimed.co.uk> <20130630213408.3e9cba96@digimed.co.uk> <20130701012918.4f1ed146@digimed.co.uk> Date: Mon, 1 Jul 2013 01:39:56 -0700 Message-ID: Subject: Re: [gentoo-user] {OT} backups... still backups.... From: Grant To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: f0168d36-5c7a-4ec4-8bba-65f015338ca8 X-Archives-Hash: b030a4356d061f162065630ef713e0f2 >> >> 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