33

I am sharing my personal Ubuntu PC with one of my colleagues.

I created another user with a different password (he knows of course) and added it to the sudoer list.

Given that there are two sudo users in a single Ubuntu system:

  • Are the private files (specified by owners and permissions) of any of these users still private?

  • Can I modify my colleague's files via sudo command, even sudo su, or vice versa?

hat
  • 233
Jizhou Huang
  • 433

6 Answers6

51

If your colleague is in the sudoers list he is root as much as you if he wants it (and he can impersonate you too), and then he can see everything.

This is the worst setup you can have if you want user privacy. You should definitively read into how user management on Linux works. Here are a few articles yo can start with:

And even then if someone has physical access to the machine in question, there is no privacy, he could drop at boot into a root shell and see everything no matter what, and if this would be password protected he could still use an USB stick and go in on this way.

So best thing in that case is proper user management, password for root, and encrypted drive and/or encrypted home directories.

Videonauth
  • 33,355
  • 17
  • 105
  • 120
  • 2
    Though make sure sudo -i doesn't work :) – Wilf Dec 01 '17 at 06:34
  • 3
    While the simplest and most common configuration of sudoers is to allow a list of users to have root privileges temporarily, sudoers allows for fine-grained control of access. For instance, you can specify that a user can execute only certain specific commands as root. If you take care to only allow a user to execute commands that don't permit creating a root shell or otherwise creating persistent root access beyond the scope of the commands you want to allow, you can avoid giving them root access in general. – bgvaughan Dec 01 '17 at 17:44
19

A simple alternative is to keep your private data in an encrypted file (could be a tar archive file, that you encrypt, for example with gpg). You must remember to overwrite and remove the clear text files after looking at them.

Another alternative for all of you who share a computer and sudo (root) access is to use encrypted home and encrypted swap.

But this will not help, if you are logged in at the same time. As a matter of fact you have to reboot the computer to get rid of your files in clear text format even with encrypted home.

In general security is very difficult, and a single user system with encrypted disk (LVM with encryption) would be the simplest way to keep things secure.

  • Do not store sensitive private data in a shared computer
  • Do not store private data in a computer that belongs to your employer
sudodus
  • 46,324
  • 5
  • 88
  • 152
  • 3
    A dm-crypt/LUKS container wouldn't have to worry about overwriting cleartext files (except for any applications' temporary files & swap), or a single encrypted ~/.Private directory with ecryptfs-mount-private – Xen2050 Nov 30 '17 at 19:04
  • 6
    This does not even protect you from evil maid attacks: the other sudo user can alter the system to trick you into giving them your passphrase. Such a question should be read as "I suspect my colleague to be a Russian spy. Should I give him sudo rights on my computer?" – sleblanc Nov 30 '17 at 20:05
  • What about a virtual machine with encrypted disk image? https://blogs.oracle.com/scoter/virtualbox-50-enhancements-and-features:-disk-image-encryption – leftaroundabout Nov 30 '17 at 22:28
  • 1
    If you need privacy, you need a single user system in other words no other user, definitely no other sudo user. The Ubuntu LVM with encryption system is vulnerable to evil maid attacks. Still I think it is better than the other easy alternatives including encrypted home. Of course, if you wish, you can have encrypted disk and encrypted home and a single user system, in order to make things more difficult for an intruder, for example according to this link, http://iso.qa.ubuntu.com/qatracker/milestones/363/builds/126342/testcases/1439/results – sudodus Dec 01 '17 at 07:06
  • All the new root user needs to do is install a kernel space rootkit like diamorphine. Doesn't even need to bother mucking around with userland LD_PRELOAD hacks: just make a simple keystroke logger, and throw it at some python scripts to do some fuzzy K-means segmentation based on time/grouping of the typing, and some text parsing, and done. Now you have the passphrase for the user and can likely get at their personal data. – Cloud Dec 03 '17 at 03:51
8

Once you are able to get root permissions (e.g. using sudo ,su,etc).
You have full access to every file on the system.

So both of the users which have sudo permission, and can became root using sudo bash will have full access to every file on the system

According to this Q&A in SE-Security: You might be able to modify SELinux (which isn't Ubuntu) in order to limit root access:

If your question is "can I easily and safely do this now?" the answer is no. If your answer is "I am prepared to learn about SELinux, get down and dirty with my distribution and put up with quite a lot of things not working" the answer is it is possible to constrain root much more than your average install. That said, this does not in any way make you invulnerable to exploits - it does not make it impossible for a user to circumvent this extra access control either in software or physically.

Yaron
  • 13,173
  • 2
    You can limit root with apparmor and selinux both, however, someone with full root access or access via the recovery shell or a live CD, with either system (apparmor or selinux) can change it back. – Panther Nov 30 '17 at 15:39
  • 1
    Even if you use SELinux or such to limit what root can do directly, they might still be able to modify the utilities the users run themselves. And if they are supposed to be able to run any upgrades, they'll need access to modify binaries on the system... – ilkkachu Dec 02 '17 at 21:16
5

To make what the other answers already stated perfectly clear: That other user is not only "root as much as you" (Videonauth's answer), they can also become you (switch to your user account).

This is because with superuser privileges, one can switch to any account.

You probably know

sudo su

which is one option of opening a root shell if root does not have a password set (so you can't just log in as root directly).

su is short for "switch user". What user does it switch to? None is stated, right? But from the man page, we can learn that:

Invoked without a username, su defaults to becoming the superuser.

So this effectively is

sudo su root

if you didn't rename root to something else.

If you just run su <someuser>, you will be prompted for a password. So if you run su root, you're prompted for root's password (which doesn't exist in Ubuntu by default, so you can't log in (note that no password being set means there is no means of logging in via a password which is different from the password being the empty string)). But if you run sudo su root, you're prompted for your own password. And you're only prompted for it by sudo. Once sudo received your password, it runs the command it received as parameters with superuser privileges. As one is able to switch to any account when having superuser privileges, a password prompt is not necessary.

So by executing

sudo su <yourusername>

, the other sudoer can log in as you.

UTF-8
  • 5,710
  • 10
  • 31
  • 67
  • +1; Yes I didn't mention this for not causing confusion, the field of protecting a machine properly is wide and filled with stones you can struggle over. Still good addition to what already has been given as answers. – Videonauth Nov 30 '17 at 19:29
  • Not sure, but doesnt sudo sualways default to UID 0 and GUID 0? If yes it should not matter how you named 'root'. – Videonauth Nov 30 '17 at 19:37
  • @Videonauth You are right with the second sentence in your second comment. This, however, is the very reason I included the sentence you're criticizing. If you rename root to john, sudo su is now equivalent to sudo su john and no longer to sudo su root. – UTF-8 Nov 30 '17 at 21:12
3

It is possible to limit the programs that can be run using sudo privilege escalation by editing the sudoers file (/etc/sudoers).

See the accepted answer to this question on Super User for further details and also here on Unix and Linux. See the answer by slm for a suggestion on limiting privileges in /etc/sudoers.

Also check the sudoers man page by typing man sudoers and don't forget to test it out. Remember that with unfettered sudo access a user can fully impersonate any other user. e.g, if user foo were to run the command

sudo exec su - bar

they would then be able to act as user bar, with all that user's privileges.

Zanna
  • 70,465
charmer
  • 49
  • 6
    Note that the specific sudoers lines shown in slm's and mtak's answers do not work to give the ability to perform some actions and not others, as it's trivially easy to use them to execute any command. (See the comments on each of those answers for detailed explanations of why.) This answer may not be strictly wrong in that it's sometimes possible to allow users to use sudo to run specific commands as root without effectively making them administrators. But it's very hard to get this right. – Eliah Kagan Nov 30 '17 at 15:47
  • @EliahKagan Right. It would be necessary to carefully ensure you don't allow them to reach a mechanism which would allow them to execute any command. Of course, it depends on the level of trust you place in the other person. –  Nov 30 '17 at 15:53
  • 1
    @EliahKagan Hence the exhortation to both read the man page and test any implementation. Limiting a user with sudo privilege is doable. However as you point out it's not a fully secure solution and some level of trust must be vested in the users that are given sudo rights. Interesting to see downvotes for an answer that recommends the use of the mechanism (sudoers file entries) that is specifically designed for the purpose of limiting the scope of the sudo command. – charmer Nov 30 '17 at 16:16
  • I think it is not about the recommendation to use a build in mechanism, so let me get to the point of what constructive critique I could give you for your answer. 1) It contains some typos and is poorly formated and looks odd when you read it, which in itself can be fixed very easily. 2) you point to other answers given outside of [ubuntu.se], here you should take the essential parts as block-quotes and post them here, making your links a part of the quotes to point to the sources you have taken those from. Hope this will help to improve your answer. – Videonauth Nov 30 '17 at 19:12
  • And since I have run out of characters in my previous comment: 3) You could go a bit deeper in explanation, point out the caveats @EliahKagan mentioned. – Videonauth Nov 30 '17 at 19:22
  • @Videonauth thanks for the comments. You are right the formatting isn't the best. I deliberately avoided block quoting those other answers as I didn't want to repeat the errors that they included. I would have hoped that the warning I gave that the sudo privilege can be easily abused to gain privilege as any user and to test (as well as read the man page) would be sufficient. I suspect that better formatting would have made that stand out better as well. The links I gave whilst not on the askubuntu.com stack are still nevertheless stack exchange sites that are relevant to the problem. – charmer Dec 01 '17 at 12:58
0

Previous answers don't apply fully, if you marked encrypt home folder while installing Ubuntu. This guarantees encrypted home folders for every user, even so root can't read the data without the proper password of the user/owner of that home folder. Your collegue would need to change your password to read the files, which would be noticed.

And of course the people are right, that sharing machines with valuable or sensitive data on it and on top of it root access with colleagues , is not a good idea.

Depending on the value of this data, I'd suggest to ask for you own machine.

s1mmel
  • 2,024
  • "Your collegue would need to change your password to read the files, which would be noticed." - Also, on any reasonable implementation, there should be no way to change the password without entering the original and still get access to the files. – Random832 Nov 30 '17 at 14:47
  • 1
    This might not preclude a root user from doing a "su -" or similar maneuver as soon as the "victim" is logged on and has the encrypted drive mounted.... there could also be a cron script or other trigger waiting for that to happen. Also, a root user could easily replace the binary handling the password input to unlock the encrypted home directory with a version that stores the cleartext password, and wait. Any security mechanisms stopping such attacks could still be levered out by changing some binary the victim will use to something that does as you want it to. – rackandboneman Nov 30 '17 at 15:00
  • 5
    I am downvoting this answer as an encrypted home directory only helps if you are not currently logged in. As soon as you log in your data is decrypted and available to the other user with sudo access. – Panther Nov 30 '17 at 15:32
  • Panther - your answers are of course legit, but this is about a shared machine. I highly doubt that both will be sitting in front of the machine the same time, at least that was my thought when I read this. – s1mmel Nov 30 '17 at 15:52
  • 2
    But why would they have to be? Even if concurrent logins are never done remotely (e.g., SSH) or with virtual consoles, can't two users be be logged in graphically at the same time, and switched between? I use Lubuntu (which has LXDE) and I'm never logged in graphically with multiple users at the same, but my impression was that more feature-rich desktop environments have supported this for a some years now and enable it by default. Am I mistaken about that? Alternatively, are the files no longer decrypted and readable by root when the screen is locked? – Eliah Kagan Nov 30 '17 at 16:01
  • 2
    IRRC the user encryption keys are stored openly on the machine to provide encryption and decryption, so a sudo su - <username> which not needs the other users password, would normally successfully decrypt the other users directory. But I could be wrong here, need to test it in a VM and will do so later. Anyways it comes in 99% of all cases down to this: "If I have physical access to your machine, you're hosed!". – Videonauth Nov 30 '17 at 19:26
  • 1
    A super user can change the login procedure to log the usernames and passwords it sees. Wait until the other user logs in and the problem is solved. – Stig Hemmer Dec 01 '17 at 09:40
  • So, as I said I conducted some tests. Outcome: If you select encrypted home at installation, the main user home will get encrypted, additional user homes will not get encrypted by default. Simple sudo su <username> is not enough to get the other users directory decrypted, however as long this second user is in the sudo group he could easily set the logging accordingly or install a keylogger to get the other users password. Then a simple su <username> with the other users password is enough to decrypt his directory. It all comes down to the statement I made above about physical access. – Videonauth Dec 07 '17 at 16:33