Hi, 17.03.2008 22:31, Sebastian Petruczynik wrote: > Hello! > I have the question to you in relation to the security. > > Let us assume the hypothetical situation that somebody is breaking into > to the workstation on which the backup is being done. > There is a configuration file of the bacula client in which the password > of the bacula storage is there after all.
No. There is only a director defined which is allowed to access this client. > Whether if somebody installed the bacula director on this station, > could he this way configure the whole in order to recover the backup on > the other workstation, > on which the backup is also being done? No. You need access to a director for this. Even if you could set up a director, given the access information from a client, that wouldn't help you - you still can't get the "fake" director to restore to another client, because the "fake" director doesn't have the access information for the storage daemon. > Or if I am using TLS encoding and the hacker could not install the > director (because there is no signed certificate) > whether could having the certificate in the customer somehow or other to > control the bacula storage? The storage daemon only accepts connections that are announced by the director. Thus, to use a fake director, you would have to modify the storage daemons configuration first. > I mean uncovering the communications protocol out between the bacula > client and the bacula storage here. That protocol is not hidden in any way, but knowing it doesn't help you much. You still need most of the configuration of the DIR to set up a fake one. Getting that information usually means having access to the DIR machine... and then you wouldn't need to set up a fake one. Alternatively, having access to the SD, you could set up a second DIR, but here, again, there's no need allow users access to the SD machine or configuration. Even if you have an unrestricted console to the DIR you can't set up new jobs there. You could restore complete clients to an external disk, for example, though. That's why you shouldn't have consoles configured on user machines, or, if you need to give your users control over their backups, you set up a restricted console, severely limiting permissions with ACLs. By design, a Bacula setup is as secure as the DIR is. That doesn't rule out bugs, though, and of course a lax security policy can always be a problem. Arno > Best regards, > -- > Sebastian Petruczynik, GNU/Linux HPC Systems Administrator > Poznan Supercomputing & Networking Center > High Performance Computing Department > POLAND > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Bacula-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel > -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
