On Tue, 02 Jul 2013 13:46:02 -0400, Josh Fisher said:
Authentication-Results: mail.pvct.com; dkim=none reason=no signature;
On 7/2/2013 11:03 AM, Martin Simmons wrote:
On Tue, 02 Jul 2013 08:32:43 -0400, Josh Fisher said:
Using PKI data encryption together with the ability to
On 7/1/2013 4:09 PM, Kern Sibbald wrote:
Hello,
This is an interesting subject and what everyone says is correct.
I have been thinking over the past few months about how to
improve security, and although we already have one way that
the FD can drop permissions to become a backup only FD,
I
On Tue, 02 Jul 2013 08:32:43 -0400, Josh Fisher said:
Using PKI data encryption together with the ability to
disable scripts would allow for fairly safe restores, since the FD's
private key would be needed to alter any files being restored and a
compromised Dir could not run
On 7/2/2013 11:03 AM, Martin Simmons wrote:
On Tue, 02 Jul 2013 08:32:43 -0400, Josh Fisher said:
Using PKI data encryption together with the ability to
disable scripts would allow for fairly safe restores, since the FD's
private key would be needed to alter any files being
On Sat, 29 Jun 2013 07:24:36 -0700, Grant said:
I'm currently pushing backups from each system to a central backup
server via rdiff-backup. However, I realized that push backups are
not safe because if one of the systems is compromised, the infiltrator
could delete all of that system's
I'm currently pushing backups from each system to a central backup
server via rdiff-backup. However, I realized that push backups are
not safe because if one of the systems is compromised, the infiltrator
could delete all of that system's backups with a command like this:
rdiff-backup
Zitat von Grant emailgr...@gmail.com:
I'm currently pushing backups from each system to a central backup
server via rdiff-backup. However, I realized that push backups are
not safe because if one of the systems is compromised, the infiltrator
could delete all of that system's backups with a
Bacula does have root read (and write) privileges on every backed-up system,
but you can encrypt the backups before sending them to the central server.
Bacula can also sign the backups, so the client can verify that a restore
doesn't contain modified data. You still have to keep the
Le 2013-07-01 13:07, Martin Simmons a écrit :
Bacula does have root read (and write) privileges on every backed-up
system,
but you can encrypt the backups before sending them to the central
server.
Bacula can also sign the backups, so the client can verify that a
restore
doesn't contain
On 07/01/13 09:11, Grant wrote:
Bacula does have root read (and write) privileges on every backed-up
system,
but you can encrypt the backups before sending them to the central server.
Bacula can also sign the backups, so the client can verify that a restore
doesn't contain modified data.
On Mon, 01 Jul 2013 15:25:23 +0200, Jérôme Blion said:
Le 2013-07-01 13:07, Martin Simmons a écrit :
Bacula does have root read (and write) privileges on every backed-up
system,
but you can encrypt the backups before sending them to the central
server.
Bacula can also sign the
Le 2013-07-01 15:53, Martin Simmons a écrit :
On Mon, 01 Jul 2013 15:25:23 +0200, Jérôme Blion said:
Le 2013-07-01 13:07, Martin Simmons a écrit :
Bacula does have root read (and write) privileges on every backed-up
system,
but you can encrypt the backups before sending them to the central
On Mon, 01 Jul 2013 16:25:06 +0200, Jérôme Blion said:
Le 2013-07-01 15:53, Martin Simmons a écrit :
On Mon, 01 Jul 2013 15:25:23 +0200, Jérôme Blion said:
Le 2013-07-01 13:07, Martin Simmons a écrit :
Bacula does have root read (and write) privileges on every backed-up
system,
On 7/1/2013 9:11 AM, Grant wrote:
Bacula does have root read (and write) privileges on every backed-up
system,
but you can encrypt the backups before sending them to the central server.
Bacula can also sign the backups, so the client can verify that a restore
doesn't contain modified data.
Le 2013-07-01 17:07, Martin Simmons a écrit :
It can be secured via ACL too.
You can manage what a client has access to.
And so, ensure no critical data pieces can be stolen through that
way.
Yes, that works as long as the Director is secure -- otherwise the
attacker
can just write
Hello,
This is an interesting subject and what everyone says is correct.
I have been thinking over the past few months about how to
improve security, and although we already have one way that
the FD can drop permissions to become a backup only FD,
I have been thinking about two additions:
1. A
I'm currently pushing backups from each system to a central backup
server via rdiff-backup. However, I realized that push backups are
not safe because if one of the systems is compromised, the infiltrator
could delete all of that system's backups with a command like this:
rdiff-backup
Bacula : Security Vulnerabilities
http://www.cvedetails.com/vulnerability-list/vendor_id-3343/Bacula.html;
(The vulnerability requires an attacker to be logged into the system
(such as at a command line or via a desktop session or web
interface).)
- Products Affected By CVE-2012-4430
#
Ralf Brinkmann ralf.brinkmann at wemhoener.de writes:
hi folks,
director and file daemon of Bacula can be of different version.
What does the vulnerability affect? - the director or the file daemon?
Director only as its related to the acl handling which only the director
does.
Marco
19 matches
Mail list logo
