jobserver.conf encrypt RepoPass

[Dan Power]

Hello,

We are looking at improving the security of our environment. It was noticed that the RepoPass is in plain text. Is there a way to encrypt it somehow or provide some other means to secure it other than plain text?

[Ronald Jeninga]

Hi Dan,

I understand your concern, but I can't think of a secure alternative than to rely on Unix file permissions.

Naturally you don't storce the conf file world readable.

Let me explain why I think that there is no more secure way to store it, and why I think that the vulnerability isn't that big.

First let me assume we implement an encryption of the password that is so secure that it is unbreakable.

Then the jobserver must decrypt the password in order to sign in to the scheduling server.

Since the source code is freely available, it would be easy to devlop a small Java program that does just that.

Thus encryption of the password doesn't secure anything.

If we add some complexity to the sign in procedure, the same is true. Just copy the Jobserver code and replace the normal processing with some attacker code.

Basically the problem is that everything required to sign in must be stored somewhere on the system that runs the Jobserver.

And it is a well known fact that security by obsucrity is simply a bad idea.

(It doesn't secure anything but it is harder to administer).

Now why do I think that the vulnerability isn't that big.

First of all, you can setup TLS communication between Scheduling Server and Jobserver.

This is definitely a good idea when parts of the network are not under your control (keyword cloud systems).

If you do so, the REPOPASS can't be sniffed.

Furthermore two pieces of data are required to sign in: the Jobserver's private key and the REPOPASS.

Since the password can't be sniffed any longer, an attacker must gain access to the system that runs the Jobserver.

If the attacker gains root access, there's nothing left to secure.

If the attacker gains access as the user X that runs the Jobserver, the attacker will be able to read the conf file.

But note, the attacker is then already able to run any process he likes as user X.

Sure, he can now sign in to the scheduling server AS JOBSERVER.

If you look at the syntax documentation, you'll find that a Jobserver can only issue a very limited set of commands.

Basically it are CONNECT, DISCONNECT, REGISTER, GET NEXT JOB and ALTER JOB. I might have missed one or two, but still, that's about all a Jobserver can do.

Hence the attacker will be able to fetch a job and not run it, or so. That would be a denial of service attack, kind of.

That could cause a bit of a mess in your job flow, but the consequences will be pretty limited.

At the same time, a bunch of responsible operators would find out quickly that something weird is going on.

(I think attckers prefer to remain unnoticed as long as possible).

I might be wrong in my considerations. If you think so, let's discuss it.

And if you know of a way to secure things, tell me.

Best regards,

Ronald