0

Ref: Can root/superuser read my read-protected files?

My Ubuntu user account name "user-3121" with type as "Administrator". There is one more account named "admin" with type as "Administrator". How can I be sure whether or not "admin" can login as me or otherwise view my files in "user-3121"?

I discussed this with the other user and we have tried to modify /etc/sudoers to protect my files:

Cmnd_Alias   SHELLS = /bin/sh,/bin/bash,/bin/ksh, /usr/bin/x11/passwd

Cmnd_Alias   SU = /usr/bin/su,/bin/su,/usr/bin/gksudo,/usr/bin/sudo,/usr/bin/su bash,/usr/bin/sudo /bin/bash,/usr/sbin/visudo

Cmnd_Alias   PASS = /usr/bin/passwd root,/bin/* * root,/bin/* * sysadmin,/bin/* * /home/sysadmin,/usr/bin/passwd

Cmnd_Alias      EDIT= /bin/* /etc/sudoers,/bin/* sudoers,/bin/* /etc/passwd,/bin/* passwd,/bin/* /etc/group,/bin/* group,/bin/* /etc/shadow,/bin/* shadow,/*/*/[a-z]* /etc/sudoers,/*/*/[a-z]* /etc/passwd,/*/*/[a-z]* /etc/group,/*/*/[a-z]* /etc/shadow,/*/*/[a-z]* sudoers,/*/*/[a-z]* passwd,/*/*/[a-z]* group,/*/*/[a-z]* shadow

Cmnd_Alias   CMDS = /usr/sbin/userdel * sysadmin,/usr/sbin/userdel sysadmin,/usr/sbin/deluser * sysadmin,/usr/sbin/deluser sysadmin

root    ALL=(ALL) ALL, !CMDS

%admin ALL=(ALL) ALL, !SHELLS, !SU, !CMDS, !PASS, !EDIT
%sudo  ALL=(ALL) ALL,!SHELLS, !SU, !CMDS, !PASS, !EDIT

admin ALL=(ALL) ALL
administrator ALL=(ALL) ALL

If "admin" can still read my data, how do I prevent that? Also how does this configuration work, it allows "user-3121" to run some sudo commands, but it doesn't actually mention "user-3121" anywhere?

P.S. I'm the only person who knows the password for the "root" user, so that I can log in as root using the "su" command.

Community
  • 1
verstappen_doodle
  • 113

3 Answers3

1

Easy, if it's an "administrator" type account then you should assume it can do anything. (Example provided below)

(Also if a user has access to your boot loader menu, or firmware configuration interface aka BIOS setup screen).

If you can run commands of your choice under user ID 0 (e.g. sudo), then you have essentially the same level of access as the process which installed your operating system in the first place. Or as one of the rescue disks you could boot from - these are able to back up all your files, or migrate them from one drive to another for upgrade purposes, etc.

Without certain TPM software (which is not implemented on Ubuntu or similar), they could install a keylogger to capture your password, or disabling any authentication checks you implement.

Per-user encryption can prevent casual access. Ubuntu community documentation last updated two years ago claims you can enable this: https://help.ubuntu.com/community/EncryptedHome

Example file access

Apparently some users think e.g. chmod 0700 protects your directories. This is incorrect. You might contrive situations where it works but it is not enough on its own. Example running on Fedora Workstation 24, ext4 filesysem:

$ mkdir secret    # directory with "secret" contents
$ chmod 0700 secret    # apply access control
$ ls -ld secret    # show access control
drwx------. 2 alan-sysop alan-sysop 4096 Nov 13 20:31 secret
$ sudo -u nobody ls -l secret    # other user ("nobody") is denied access
[sudo] password for alan-sysop: 
ls: cannot access 'test': Permission denied
$ sudo ls -l secret    # but root user bypasses access controls (CAP_DAC_OVERRIDE)
total 0
sourcejedi
  • 50,249
  • What if there are two administrator users? One can read another's files without password? – verstappen_doodle Nov 12 '16 at 17:38
  • Easy, if it's an "administrator" type account then you should assume it can do anything. – sourcejedi Nov 12 '16 at 17:41
  • 1
    I guess that is wrong. That actually defeats basic security. Some reference may be helpful. – verstappen_doodle Nov 12 '16 at 17:54
  • He only has the priviledges afforded in the sudoers page, so he cannot do everything. For instance, he cannot sudo su. Anyway this is really thorough. I don't think we're dealing with a boss who uses keyloggers – trudgemank Nov 12 '16 at 18:37
  • also I don't believe all those exceptions were necessary. just taking away his sudo rights should do it. – trudgemank Nov 12 '16 at 18:47
  • 1
    @unix_root I have improved my explanation, with reference to the capabilities of common boot discs. What do you consider "basic security" once you're running commands of your choice as root? – sourcejedi Nov 12 '16 at 20:14
  • Ahem, changing the permissions of the file was not all he did. The other user simply does not have the permissions for it. And he cannot change the permissions, because he does not have root access. – trudgemank Nov 14 '16 at 06:15
  • 1
    With "sudo", he can see anyone's files even though it has 0700. – verstappen_doodle Nov 14 '16 at 17:23
  • that's not true. try it. – trudgemank Nov 15 '16 at 05:02
  • Tried in Ubuntu and Kali. It worked. Just do "sudo su -", and you'll be logged into root. Make sure, "root" account is enabled in Ubuntu. Also, I am able to view other "Administrator's" files with 0700 with just "sudo". – verstappen_doodle Nov 15 '16 at 12:00
1

Ok, now I understand what this is saying

Cmnd_Alias   CMDS = /usr/sbin/userdel * sysadmin, ...
%admin ALL=(ALL) ALL, !SHELLS, !SU, !CMDS, !PASS, !EDIT

unfortunately it is a terrible idea.

In security, a general principle is you should be able to describe what you're allowing. It's surprisingly rare to be able to make a list of what is not allowed, and be sure you haven't missed anything.

Specifically

$ cp /usr/sbin/userdel ./letsbefriends
$ sudo ./letsbefriends sysadmin

(and the same principle applies to a configuration which specifically blocks sudo su / sudo sudo).

As a postive example, consider this listing of allowed tasks for your "admin" user [*]:

# admin can run `reboot`.  (They can't run e.g. `reboot --force`).
admin ALL=(ALL) reboot ""

Why [is] "user-3121" missing in /etc/sudoers?

Excellent question! user-3121 is a member of the sudo group. In /etc/sudoers, this group is matched by the line %sudo.

You might think "That's a cute hack you've showed me. Surely I could think of a way to block that as well". And there are approaches you could take. But you would be arguing for the sake of it, and trying not to accept the general principle.

Someone else comes along, with a different idea. What does this do? [**]

$ sudo /proc/self/exe sh

That's two different examples you would have to configure your system to block. You can trust I know more. You end up writing this complex custom configuration. Complex systems inevitably include bugs. Did you want to create a custom system, troubleshoot and maintain it? Usually you want to try and work with the operating system you installed, so you can benefit from all the work that goes into developing, documenting and supporting it.

[*] In practice, limiting sudo to a certain purposes does tend to be more difficult than one might like. I expect it is not common to rely on sudo rules to provide a true security barrier. Instead, it's used to delegate permission for specific tasks, while protecting users from themselves. It reduces the chances of making a mistake and writing zeros all across their valuable hard drive, or the firmware on the network card.

[**] Spoiler:

sudo /proc/self/exe sh would run a shell as the root user.

It bypasses the blocklist defined as SU, using the same technique of running a command (sudo) using an alternative filename which is not on the blocklist. So this second instance of sudo is successfully run as the root user. The posted configuration allows the root user to run any command through sudo. The second sudo instance is therefore allowed to run a shell as the root user.

The resulting shell can be used to run any command as root. The shell does not use sudo, so it does not look at any lists of blocked commands in sudoers. E.g. the shell could run su to log into a shell running as any given user, without knowing their password.

sourcejedi
  • 50,249
  • 1
    I recommend you merge both your answers into one answer (i.e. delete one and merge its text into the other) as they are essentially saying the same thing. (You are completely correct; it is impossible to secure anything with a sudo blacklist.) – Wildcard Nov 12 '16 at 20:19
  • @sourcejedi A shell would not work here. If you look at the /etc/sudoers file you'll find that the sudo group does not have permissions to run a shell as root. – trudgemank Nov 14 '16 at 06:17
  • In my defense that "sudo blacklist" was not my idea, it was his admin's. But regardless your answer is wrong, he does not in fact have to "block" either of your approaches. Try it yourself, you will get "cannot execute XXX as root, sorry" errors. – trudgemank Nov 14 '16 at 06:29
  • But the "decide what to allow" approach is definitely better, you're right about that. Like iptables. One other thing, he does not have the permissions to use dd either. – trudgemank Nov 14 '16 at 06:39
  • '/proc/self/exe -i won't work either, you'll get another "not allowed to xecute as root" error. – trudgemank Nov 14 '16 at 06:49
  • Anyway, if he were to put in the sudoers file only priviledges allowed, what ones would be allowed? The + does this. – trudgemank Nov 14 '16 at 06:50
  • What I'm trying to get at is I resent being called "some users", and my answer works. :/ – trudgemank Nov 14 '16 at 06:58
  • @trudgemank you were not the only one as far as I could tell :). unix_root also asked "What if there are two administrator users? One can read another's files without password?", and then rejected my answer (which was in the positive). How would you prefer I referred to the two of you? My instinct is not to call people out by name because that doesn't answer the question. – sourcejedi Nov 14 '16 at 09:41
  • @trudgemank if you're arguing neither of my approaches would bypass these blocks, then we should focus on the first one. I'm not very interested in debugging / tracing a kilobyte of someone else's code, nor installing it on my system. I'm not following your explanation. It would be very helpful if you pointed out the specific configuration steps, that prevent the "admin" user from copying userdel or sudo to my home directory as a-safe-command, and then running sudo ./a-safe-command with whatever arguments they like. – sourcejedi Nov 14 '16 at 09:53
  • @trudgemark I used ctrl+F to search this page for the + character. The only instance I could find was your comment here. So I don't understand how the + character is relevant to the configuration in the question (or the answers). I provided an example of only allowing a specific command, it does not use the + character. – sourcejedi Nov 14 '16 at 09:58
  • clarification: to my home directory: to their home directory – sourcejedi Nov 14 '16 at 09:59
  • My "solution" is basically make the file 0700 and then nerf his priviledges. As for + I'm talking about how to add priviledges selectively in sudoers.list – trudgemank Nov 15 '16 at 05:06
  • @trudgemank Does this mean you want to request an edit for the answer you posted, to say that what you meant was to remove the "admin" user from any group listed in sudoers? And remove "making sure only root has permissions to edit /etc/sudoers" because those lines don't help and can only confuse people? – sourcejedi Nov 15 '16 at 08:35
  • In my case, "admin" was in %sudo group and also exists in sudoers as "admin ALL=(ALL) ALL". I deleted that line and also did "sudo deluser admin sudo". ^_^ – verstappen_doodle Nov 15 '16 at 12:07
  • @sourcejedi yeah, I kinda gave up on my answer. My philosophy is "do what I know and dont resort to google search". I play around and troubleshoot, sometimes this involves complicated yet not-so-efficient solutions. that's very naughty of your unix root! That's something no one has mentioned. Are you allowed to be doing this??!! Will your admin be po'd? Am I an accessory to a crime? – trudgemank Nov 18 '16 at 13:51
  • @sourcejedi You saw this exploit? This says This allows any Sudoer user to obtain full root privileges. I'm more confused now? You said that sudoers and root has same rights!? Am I missing something here? – verstappen_doodle May 31 '17 at 11:38
  • If sudoers are designed actually to do everything that root can do, then what is the necessity of this exploit? – verstappen_doodle May 31 '17 at 11:45
  • @unix_root I said no such thing. I said I expected it is common for people to set up sudo rules, without expecting them to be completely secure against abuse. I expect it's also common not to think about them too hard. Or as in this question, to think about them for a long time and just get it flat wrong. It's still theoretically possible to set up sudo rules which can't automatically be abused to provide root access. E.g. allowing the use of lprm to delete print jobs from any user. But you can't expect to do a wide range of sysadmin tasks through sudo, and not be root-equivalent. – sourcejedi May 31 '17 at 11:54
  • // But you can't expect to do a wide range of sysadmin tasks through sudo, and not be root-equivalent. // But, a suoder can gain root by sudo /proc/self/exe -i. Now, he gained complete root, am I right? Can root prevent this escalation done by a sudoer? – verstappen_doodle May 31 '17 at 12:04
  • @unix_root please actually read what I am saying. How are you going to run sudo /proc/self/exe -i if the sudo configuration allows your user to run /usr/sbin/lprm with the arguments of your choice, but not any other command? – sourcejedi May 31 '17 at 12:08
  • Uh, I forgot about that whitelisting commands thingy. I got it now. (Y) – verstappen_doodle May 31 '17 at 12:25
0

Okay, summarizing the chat for anyone who has this question. Basically what he did is change permissions of his home directory to 0700 (only he can read write execute)

chmod 0700 /homedirectory

Then the rest of the chat was trying to make sure that the admin couldn't su him or sudo su him. (Yes he could normally get the files in other ways but he doesn't have the permissions.) This entails changing the permissions given in /etc/sudoers and making sure only root has permissions to edit /etc/sudoers.

trudgemank
  • 317
  • 1
    This worked only when "admin" don't have sudoers rights. Else, "admin" can run "sudo su - user-3121" and enter admin's password and happily su'ed user-3121. So, only way to prevent "admin" to see user-3121's files is to remove him from sudoers list. – verstappen_doodle Nov 12 '16 at 16:48
  • Also, note that, doing "sudo deluser admin sudo" from root has no use. You have to manually change "admin ALL=(ALL) ALL" to "admin ALL=(ALL) ALL, !SU" in /etc/sudoers. (Refer !SU alias code in the question - revoke su binaries to admin) – verstappen_doodle Nov 12 '16 at 17:02
  • (to be explicit, controlling su doesn't help either, sudo already gives you CAP_DAC_OVERRIDE – sourcejedi Nov 12 '16 at 17:11
  • How about this: admin ALL=(ALL) ALL, !SHELLS, !SU, !CMDS, !PASS, !EDIT Can "admin" su me with his password (without my password)? – verstappen_doodle Nov 12 '16 at 17:13
  • oh, you're giving admin the same priviledges as admin group? He can't su you but I'm afraid he'll be annoyed if you change his permissions... – trudgemank Nov 12 '16 at 18:35
  • but its kind of funny. you're giving him the priviledges he gave you :) – trudgemank Nov 12 '16 at 18:39
  • I'll try again. admin doesn't need to su to you. admin can run sudo commands, which have the capability to view (or change) all your files. The "login as me" part doesn't really matter. – sourcejedi Nov 12 '16 at 20:02
  • sudo doesn't have root permissions on his computer. they are different. he can only do those things as root. he knows because he tried viewing admins files with sudo, he can't. just with root, and admin can't sudo su – trudgemank Nov 13 '16 at 06:57
  • @sourcejedi How can he view my files with just sudo, if I have 0700 file permissions? – verstappen_doodle Nov 13 '16 at 20:24
  • @unix_root by viewing your files with sudo. For a worked example please see new section "Example file access" of my answer. – sourcejedi Nov 13 '16 at 20:45
  • Oh my. So, basically sudo is pure "root" permission. -_- – verstappen_doodle Nov 13 '16 at 20:52
  • by default it is. but your sudo is not. did you read his sudoers file? ALL,!SHELLS, !SU, !CMDS, !PASS, !EDIT <<<< he can't do all of that stuff. sudo is basically equivalent to admin priviledges. – trudgemank Nov 14 '16 at 06:05
  • @trudgemank what does this last sentence mean? You're saying there's something called admin privileges, which is something different from "pure root"? What is this concept of admin privileges, where can I learn what it means (where in the code or documentation or community documentation / support messages)? – sourcejedi Nov 14 '16 at 10:04
  • @trudgemank, if you have "sudo" rights, you can do everything "root" can. – verstappen_doodle Nov 14 '16 at 17:23
  • look at the sudoers.list. "sudo" group has the same priviledges as "admin" group. and yes, sudo can do everything root can by default, but your admin changed it so that it doesn't have root permissions – trudgemank Nov 15 '16 at 05:01
  • No, it doesn't work that way. That's what @sourcejedi said. Blacklisting can always be bypassed with just "sudo" capability. Just copy /bin/su to your home as "./sutemp", and execute it to login as root. "sudo ./sutemp -" will do it, where sutemp is copied from /bin/su to your pwd as "sutemp". FYI, I am able to login as "root" from user-3121, with just my password. The same sudoers file in the question is used. – verstappen_doodle Nov 15 '16 at 12:04
  • Oy. sourcejedi is more learned than I but apparently less perspicacious. Look at your sudoers list. looks at roots priviledges. now look at the sudo group. they are different. so sudo cannot do everything root can, try it yourself (I did). sj is talking about sudo by default. your admin changed its priviledges. – trudgemank Nov 18 '16 at 13:41
  • I tried what you mentioned. No permission to execute the script as I thought. I don't know why it's not working for me :/ It may have been some security thing I set up and forgot about. – trudgemank Nov 18 '16 at 13:52