Permissions – Create a Super Super-User to Deny Root Permissions

permissionsrootsudousers

I was thinking that it might be advantageous to have a user with permissions higher than the root user.

You see, I would like to keep all of the activities and almost all existing root user privileges exactly as they are now.

However, I would like the ability to deny privileges to root on an extremely isolated case by case basis.

One of the advantages of this would allow me to prevent certain unwanted files from being installed during updates. This is just an example of one possible advantage.

Because apt-get updates are run by root or with sudo privileges, apt-get has the ability to replace certain unwanted files during updates.

If I could deny these privileges to these individual particular files, I could set them as a simlink to /dev/null or possibly have a blank placeholder file that could have permissions that would deny the file from being replaced during the update.

Additionally, I can't help but be reminded about a line which was said in an interview with one of the Ubuntu creators when the guy said something about how users better trust "us" (referring to the Ubuntu devs) "because we have root" which was a reference to how system updates are performed with root permission.

Simply altering the installation procedure to say work around this problem is absolutely not what I am interested here. Now that my mind has a taste for the idea of having the power to deny root access, I would like to figure out a way to make this happen just for the sake of doing it.

I just thought about this and have not spent any time on the idea so far and I'm fairly confident that this could be figured out. However, I am curious to know if this has already been done or if this is possibly not a new idea or concept.

Basically, it seems like there should be some way to have a super super-user which would have permission beyond that of the system by only one degree.

Note: Although I feel the accepted answer fits the criteria the most, I really like the answer by @CR. also.

I would like to create an actual user higher on the tree (me) but I guess I'll just have to sit down one day when I have the time to figure it out.

Additionally, I'm not trying to pick on Ubuntu here; I wouldn't use it as my main distro if I felt negative about it.

Best Answer

The "user" you want is called LSM: Linux security module. The most well known are SELinux and AppArmor.

By this you can prevent certain binaries (and their child processes) from doing certain stuff (even if their UID is root). But you may allow these operations to getty and its child processes so that you can do it manually.

Related Solutions

Why sudo Command Executes Without Prompting for Password

Say sudo -K, then retry your test. If it starts asking again, all that was happening is that you had sudo configured to remember your password for some time.

On top of this, Ubuntu's default sudo configuration makes it remember your credentials across ttys. This affects ssh sessions, as you've discovered, since each new ssh connection looks like a new terminal to the low-level OS code.

This also affects things like the graphical Terminal app. If you authenticate with sudo, then create a new tab with Ctrl-Shift-T, you'll find that you don't need to give a password to sudo again in that tab, despite the fact that it also creates a new tty. You can even close the Terminal app entirely, and as long as you restart it within the normal password timeout, sudo will run without requiring you to re-enter your password. This behavior may be enough to make you decide you want to keep this feature enabled.

Mac OS X works this way these days, too.

Not all *ixes do. Red Hat Enterprise Linux (and derivatives like CentOS) insist on getting the password on each new tty.

You can disable both behaviors by changing the Defaults line in /etc/sudoers to something like this:

Defaults=env_reset,timestamp_timeout=0,tty_tickets

The env_reset bit should be there already, and isn't relevant here
The timestamp_timeout directive tells it to immediately time out each sudo session. It's like saying sudo -K after every normal sudo command.
The tty_tickets directive ensures that it associates credentials with the tty they were used on, not just the user name. This is supposed to be the default already, and is documented as such on Ubuntu, but they must have built their distribution of sudo to disable this option, for the convenience reasons given above.

How to execute a command that requires root permission without sudo

traceroute need not run as root; it just needs the capability CAP_NET_ADMIN. Thus you can set this as file capability for the file and then traceroute will always have this capability (for all users, though), if your kernel supports file capabilities and no Linux Security Module (SELinux, AppArmor) is blocking it:

setcap CAP_NET_ADMIN+ep /usr/sbin/traceroute

While traceroute is running you can see its capabilities with pscap. This does not affect the UID/EUID of the process.

I don't know how to do that but AFAIK it is possible, too, to use AppArmor (and probably SELinux) to run a process with certain capabilities. The main task is, of course, to limit the available capabilities.

Best Answer

Related Solutions

Why sudo Command Executes Without Prompting for Password

How to execute a command that requires root permission without sudo

Related Question