Hello,
If you have hundreds of users with root access and they can access
the Bacula Director machine as root, you have a far bigger
security problem than just Bacula, since they can do anything to
your machines and the Bacula Director machine, and there is no way
Bacula could ever avoid it.
Root access to your Bacula Director machine gives the person
access to everything including everything in Bacula. On *nix
machines that is normal and it is unavoidable.
Thus in a network such as yours you must be careful never to allow
external root access to any machine you want to be secure. Access
should always be via a user id and password, and sudo root access
should always be disallowed to everyone except trusted
administrators. There are, of course, other more complicated ways
to accomplish the same thing.
Bacula has been around for 15 years now, and if there were a
serious security design error, it would have been pointed out a
long time ago. I assume you already understand my comments about
sudo and root access, and I am sure when you fully understand
Bacula's security and apply "normal" *nix security (sudo, ...) on
top of it, you will have a secure backup system.
Best regards,
Kern
On 12/18/2015 05:34 PM, H. Steuer wrote:
Hello Bill,
you are right, but there is a serious side effect. Heres a
statement from the Bacula docs:
The first console type is an anonymous or
default console, which has full privileges. There is no
console resource necessary for this type since the
password is specified in the Director resource.
Typically you would use this anonymous console only for
administrators.
So this means that - as there is no configuration item for the
anonymous console in the "bacula-dir.conf", it uses the
password from the "Director" section. As this is also the
password thats used for the director to access the client file
daemon, we have now the result that this is the same password
that can be used in a "Director" section of the
bconsole.conf. I just gave it a try and changed the password
in the Director section of the bacula-dir.conf. Then I have
chosen a random client, installed bconsole, created a
bconsole.conf with the same password and voila - had full
access
to all the backups.
So the final result is that you can always use the same
password in the bconsole.conf Director section as the one
thats
configured in your bacula-fd.conf Director section which then
grants you administrative privileges in the director.
Thanks for your support so far, let me know your thoughts....
Cheers,
Heri
On 18.12.2015 17:19, Bill Arlofski wrote:
On 12/18/2015 10:30 AM, H. Steuer wrote:
Hello Bill,
thanks for your explanation. I fully understand your point. However, if a user
has root privileges on one host which is backed up, there is already a file
daemon config that holds
the director password. Please correct me if I´m wrong, but my understanding is
that the anonymous console does not require (and cannot have) a "Console"
configuration
on the director. Therefore such a root user could install the bconsole client
on his host, configure the bconsole towards the director with the password
grabbed from the
file daemon and then connect to the director.
The password in the Director {} resource of the bacula-fd.conf file on a
client is the password that the Director must supply to connect to the FD, not
the other way around.
Try it. :) Try using this password in a bconsole.conf file and attempt to
connect to the Director. You will be denied access.
On the Director, a Client {} resource needs to be created where a matching
password is set for each FD.
Hope this makes it a little more clear.
Bill
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|