On Friday 21 October 2005 19:38, Phil Stracchino wrote: > Viktorija wrote: > > what about Windows type client? I don't need administrator rights for > > stolling such file :)
Actually, Viktorija, using some clever insight, has brought up an interesting problem. If you have a brain-damaged machine such as Win98 or WinXT home, then you cannot protect the Bacula .conf file, and in that case, it is possible for someone with access to the machine to steal the .conf file. There are several answers to this problem: 1. Tough luck, if you have a brain-damaged machine, it is not possible to protect the passwords. 2. If you have a brain-damaged machine, it is a whole lot easier to simply copy the files directly rather than using a fake Bacula Director to take the files. Yes, but I don't really like either answer or rather I should say that neither is really very satisfactory. After thinking about this a bit, I remembered that I had planned a feature that could help a bit -- at least it could prevent someone from easily subverting Bacula. The feature is an "Address = xxx" directive in the Director resource of the File daemon's conf file. This directive exists since the beginning of Bacula, but it is neither required or currently used. The idea was that if an Address is specified that Bacula would then *require* that the Director that is calling is at the specified address. This is sort of a simple minded libwrap feature. So, bottom line: - On systems with file permissions, you should definitely protect the .conf file. - On systems with libwrap (Unix, Linux, but not Win32), you can restrict the Director to come from a specific IP address. - On other systems, we could implement the "Address" directive which would be a small additional protection. I'll leave it to the users during the next feature vote (in November) to decide if this is important or not. Best regards, Kern > > But you're using restricted consoles on your Windows clients that allow > access only to jobs saved for that machine, right....? Or maybe you > don't even HAVE a console installed on the Windows client, in which case > our hypothetical thief can't get the director to give him any data > because the client has no permission to open a console session. > > I'm fairly sure you'll find compromise of a client, unless the client > has a full, unrestricted console, does not get you access to any data > that wasn't already on the client you compromised in the first place. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
