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.

  • That isn't helpful, as I don't know what are all accessible by user "admin", and relate with sudoers. – unix_root Nov 12 '16 at 13:14
  • It answers "How do I know whether "admin" can login as me and view my files in "user-3121"?" – trudgemank Nov 12 '16 at 13:17
  • You aren't in sudoers because you didn't make yourself a sudoer. But you already have sudoer permissions since you are in the group admin. – trudgemank Nov 12 '16 at 13:19
  • If you want the other admin to not be able to access your files you'll need to change their permissions. If you are the only one with the root password just make a local sudoers file for "admin". – trudgemank Nov 12 '16 at 13:20
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.

  • 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 6: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 6: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 6: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 6:49
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
  • What if there are two administrator users? One can read another's files without password? – unix_root 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. – unix_root Nov 12 '16 at 17:54
  • 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
  • 1
    With "sudo", he can see anyone's files even though it has 0700. – unix_root Nov 14 '16 at 17:23
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.

  • 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. – unix_root 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) – unix_root 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)? – unix_root 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

Not the answer you're looking for? Browse other questions tagged or ask your own question.