1

We have a CentOS development server that has source code for various projects. Some of the projects are more sensitive than others and for those sensitive projects we'd like to restrict access to only a certain group of developers (all developers are in-house). The catch is all the developers on our server have root access because of the nature of what they're doing (I know, shame on me).

I'm exploring ways to protect certain source code repositories from certain developers and have come up with the following ideas: Encryption like Truecrypt with a password only known by some users, a change root jail, a virtual machine, or a totally separate server. Obviously they all have their pros and cons. I wanted to gather some suggestions and additional ideas. What's the best way to protect source code from prying eyes on a server even from users who have the root password?

Thanks guys! ~Dan

Dan
  • 657
  • 2
  • 9
  • 13
  • An encrypted home directly is easy to set up and should do what you need. – Joel Jun 16 '11 at 14:55
  • 9
    Don't forget handcuffs and automatic weapons. These are after all your colleagues. Can never be careful enough with those... – Dirk Eddelbuettel Jun 16 '11 at 14:55
  • 3
    @Joel: If they have root access it would be easy to put a monitor in place that would check for the directory to be unencrypted and then extract the encryption key from RAM, or just copy the data – Daenyth Jun 16 '11 at 14:56
  • Irony - posting to a link with a bunch of open source tags, to open source enthusiasts, to figure out how to keep others from viewing source. Do you work for NSA or something? –  Jun 16 '11 at 15:09
  • 1
    @nsfyn55: Even more ironic---if the OP worked for NSA, the OP would know that NSA has a project called SELinux that _might_ just be able to defend against that sort of thing. I haven't used SELinux though, so I can't say more. – C. K. Young Jun 16 '11 at 15:17

4 Answers4

6

If a user has root, they can do everything. Even encryption or chroot jails are not going to protect the system from root users.

For example, it wouldn't be hard to write a program that detects when your decryption program is being run, and trace it so that the decryption key can be captured.

(Installing trojans is even easier, but I'd like to think you have systems in place to detect that! Though, a root user could feasibly disable those detection mechanisms too. Who are you trying to defend against?)

C. K. Young
  • 1,862
  • 16
  • 16
  • I guess I should clarify the goal is to make it more difficult as apposed to impossible for them to gain access to certain source code repositories. We just want to expose to them the projects that they're working on and not the projects that they're not working on. If they want to go through the trouble of breaking into areas they shouldn't then it's not the end of the world for us. We trust our staff but there is the occasional turnover so we wanted to take steps to make sure a staff member couldn't walk away with all our code in a sudden fit of rage. –  Jun 16 '11 at 15:13
  • 1
    @Dan: Most kinds of leakage are not done in "a sudden fit of rage", but is quite premeditated. What do you think Cablegate is? Jus' saying. – C. K. Young Jun 16 '11 at 15:15
1

Why do they need root access? You can control superuser permissions with sudo so that they can do necessary things (like restarting a daemon) but can't look at code that doesn't concern them.

Zhehao Mao
  • 186
  • 3
0

What about creating a Unix group for restricted-access developers. You would then be able to set Unix permissions to this new group only, so that non-members would not have access to your sensitive projects location.

But if a user has the root password (why would he?), I don't think you'll be able to protect anything.

jopasserat
  • 411
  • 4
  • 8
0

What you ask is not possible with your broken workflow. If a user has root they can eventually bypass any restriction you put in place, even encryption.

Daenyth
  • 243
  • 1
  • 7