> 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
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
> 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
On 07/02/2013 02:32 PM, Josh Fisher wrote:
> 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
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
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 co
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
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 cont
> 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 b
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 th
> 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 al
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
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 co
>>> 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 th
Zitat von Grant :
>>> 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
>> 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-b
> 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 sy
Ralf Brinkmann 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
---
18 matches
Mail list logo
