0

I'm new to Linux (Ubuntu if that matters). My company has several sudo users on a machine. The situation is like this:

  1. Everyone wants sudo user privilege because they claim they need to install python packages during their work (they are AI engineers)

  2. Each user keeps private rsa keys in their home folder to quickly pull/push to github.

So theoretically if a sudo user goes rouge, he can just grab everyone's private key and impose them and pull the source code he's not entitled to. How do I prevent that from happening?

Thanks

EyeQ Tech
  • 115
  • I've not used it but anaconda and conda seem to provide for personal python package management that might be an alternative. – meuh Oct 19 '19 at 09:37

3 Answers3

5

I'm not giving you a direct answer to your question, since you're describing an XY problem. This is your underlying, actual problem:

Everyone wants sudo user privilege because they claim they need to install python packages during their work

The issue is this: nobody needs to use sudo to install Python packages. In fact, that is highly discouraged. Particularly if you have multiple people using the same system, you couldn't prevent anyone from messing with system-level packages that others might require. What if there are version conflicts, breaking changes in some packages, etc.?

Solution 1 — User-level Installations

The real solution is to use user-level installations of Python packages. That is, instead of sudo pip install …, do:

pip install --user pandas

This will install the package into the respective user's home directory and leave the system package library alone.

I cannot stress this enough: nothing good ever comes from using sudo with pip.

Solution 2 — Pipenv or Poetry

An even better solution involves using pipenv or poetry, which create a virtual environment for packages to live in.

The packages and versions can even be different for different projects — this is particularly important if you need a package to stay at a given version for a while (e.g. pandas is notorious for changing its API; scipy has had some breaking changes a while ago, …).

I would have recommended Pipenv, but as of 2020, maintenance has been quite lacking, and there hasn't been any release for ages.

To use Poetry, just install it on a per-user level:

pip install --user poetry

Then initialize a new environment for the current project:

cd /path/to/project
poetry install pandas

This will create a new Poetry config file that specifies the requirements for the current project. Run poetry to find out more or read the documentation.

Solution 3 — pyenv

The best way to go about this would be to have users install their own Python version. You can use pyenv to create user-level installations of whole Python distributions. This way, users can use whatever Python version their Pipenv project was initialized with, e.g. stay at 3.7 for a while until they want to upgrade to 3.8.

This is particularly nice if you don't want to break everyone's packages by performing a system-level minor upgrade of Python, should it ever be required.

Bottom line: Don't give regular users sudo access if you don't need to. Have them use their own userspace for installing Python and/or Python packages.

Caveat: Some Python packages may need specific libraries in order to be built successfully. You cannot really avoid system-level installations of these libraries, but in such rare cases, an admin might be willing to sudo apt install … whatever library is needed.

slhck
  • 228,104
2

Presumably the Python developers are connecting to this machine remotely using ssh rather than logging in directly on the console.

In that case, then their private keys should not be on the shared machine at all, for precisely this reason. Instead, they should run ssh-agent on their local machines and connect to the shared machine using ssh -A (or set ForwardAgent yes for that host in ~/.ssh/config) and keep the private keys only on their local machines. Using ssh-agent and agent forwarding will cause the remote (shared) machine to securely forward authentication requests (such as from github) back to the ssh-agent on the user's local machine, where the RSA authentication will be performed without having to ever disclose the user's private key to any host other than their local machine.

(If the local machine is running Windows rather than a linux/unix variant, then the Windows ssh client should still provide ssh agent forwarding in some manner, but I don't know how it would be accessed. Check your documentation for details.)

Dave Sherohman
  • 5,403
  • My assumption is that users will have their private/public key pairs on the development machine in order to push/pull from remote repositories. – slhck Oct 19 '19 at 09:07
  • @slhck - And the point of this answer is that users don't need to, and shouldn't, have their keypairs on a shared development machine, because they can push/pull from remote repos while keeping their keypairs solely on their local desktop machines. – Dave Sherohman Oct 19 '19 at 10:22
  • @DaveSherohman I understand your point. Thanks. But I think I really asked a not-so-good question (XY problem) as shlck pointed out. Basically even if everyone's home folder (on the shared machine) doesn't keep ssh key, a sudo user can just "view the code" after it's pulled to the machine. – EyeQ Tech Oct 19 '19 at 16:55
0

The solution would be to give the python developers permission to only sudo the commands that they actually need. The permitted commands are entirely specified including arguments, and wildcards are possible.

The following is an answer from the Unix Stackexchange post
How to remote execute ssh command a sudo command without password.

you can tell sudo to skip password for some command.

e.g. in /etc/sudoers

archemar  ALL = (www-data) NOPASSWD: /bin/rm -rf /var/www/log/upload.*

this allow me to use

sudo -u www-data /bin/rm -rf /var/www/log/upload.*

as archemar without password.

Note that

sudo -u www-data rm -rf /var/www/log/upload.*

won't work (will ask a password) as rm differ from /bin/rm.

Be sure to edit /etc/sudoers using visudo command.

Once you've reach advanced level, you might wish to have your own sudo files in /etc/sudoers.d.

harrymc
  • 480,290
  • 2
    Note that, if you take this approach, you need to be very careful about which commands you allow sudo execution of. If you allow any command which can be used to invoke a shell, then users could get an unrestricted root shell, and commands which allow alteration of arbitrary files could be used to change sudo-allowed scripts to give unintended access. – Dave Sherohman Oct 19 '19 at 08:59