3

At our company the Linux system administration is handled by the security team. The guy assigned to my project has been a great big pain, and has seemed to me at several points to be of questionable competence. (Maybe he's qualified to be a junior sysadmin, but not a security expert who also handles Linux system administration. Perhaps he's good with other aspects of security or something I'm not aware of, but he's said things that make me question his competence in this particular role.)

He locks things down in ways that make my job very difficult, and without any good reasons that I can see or that he can explain to me. (E.g. I can't use chown or chgrp on files I own, and he claims that giving me that ability would be a security hole.) If I trusted his general competence more I would assume that he simply understands things I don't understand.

One thing that is a thorn in my side is that I have to use sudo before drush (a script used for command line access to Drupal servers) and this breaks drush's ability to communicate with other servers, since it's not running under my credentials and therefore the use of ssh keys is screwed up.

It occurred to me, though, that since

  1. drush can run arbitrary command aliases
  2. drush is running with root privileges

I can now run arbitrary code on that box. I tested with an alias to whoami and it returned root, so it appears that I do in fact now have the ability to gain root privileges.

What should I do?

Although (in effect) he gave me root access, I think actually using it would be a really bad idea. (Although it's really tempting: I might actually be able to get some work done now!)

Is it my responsibility to do more than report this problem? And to whom???

Am I responsible to report (what I think may be) the problem behind the problem? In other words, his lack of suitability for this particular role? Although I'd really like to not have him on my project I don't want to cost him his job.

Or is there something else I should do that I'm not even thinking of?

UPDATE: I should have mentioned that this sysadmin is on vacation today, so I can't report it to him until Monday at the earliest. I don't know if this changes anything, or suggests a need to report to someone today?

Improve this question
1
  • 1
    Without something like sudo, unprivileged users don't have the ability to chown their files to another user. But they do have the ability to set the SUID bit on their own files. So allowing you to chown your files to root would allow you to create SUID root programs :).
    – sourcejedi
    Oct 6, 2012 at 16:56

2 Answers 2

Reset to default
7

Although it depends on the local policy of your organization, the usual setup is that you should report the issue; actually, make it a must since your sudo call with whoami was logged (sudo keeps logs by default) and this proves that you were aware of the issue. You have crossed the threshold, now you must go to the end of it.

If you consider that the hole is an honest mistake, then you should report to the sysadmin himself. On the other hand, if you have rational reasons to believe that the sysadmin has planted a hole intentionally, then you should report the issue to his manager.

Either way, the sysadmin will hate you for that.

Improve this answer
1
  • I have no reason at all to suspect he would put it there intentionally.
    – iconoclast
    Oct 5, 2012 at 18:45
3

It's a security hole. Report it to the first available security team member. If he's on vacation mail him, and forward the mail to his supervisor or copy him in. "Sorry to bother you in a vacation day but"..... might be a good start. Good luck.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .