Major security and usability flaw in Linux (root privileges and sudoers, folder access restriction, Ubuntu Linux)

Alright, let me give you the context. I am a business owner with strong technical background, say a programmer, though not an advanced system administrator. I’ve bought a VPS server where I want to host several applications and webpages. One of the apps consists of backend, admin frontend and user frontend, another one is just backend and frontend. So 5 different programmers develop those apps. From time to time, as the development takes its place, those programmers need to install and upgrade some packages, modify system configs and so on, i.e. they need ssh access and some root privileges.

And here is the tricky part. It is obvious that I don’t want them to see and gain access to the folders they are not supposed to see, i.e. the devs of the first app shouldn’t have access to the folders of the second app and vice versa. Moreover the backend dev of the first app shouldn’t have access to the frontend folders of the same app and the same goes for the second app. Also I would like to restrict access for them to certain commands like visudo or reboot, so they wouldn’t be able to lock me out of my own server or reboot it without my consent.

Now, if I give them sudo privileges for them to be able to run administrative tasks needed for their development – then they have access to everything and it becomes practically impossible to restrict access for them to certain folders and commands. On the other hand if I DON’T give them sudo privileges, then it becomes a huge pain for me to every time install packages and give them access to certain files and commands they need to continue development. There are over 1500 commands and the corresponding number of system files in Linux they could potentially need access to, so it’s very VERY unconvenient for me to spend so much time to administer the VPS, especially getting the fact that I’m not a very advanced system administrator and I don’t have much time because I need to run my business.

There are already numerous posts and threads on the Internet where people try to find solutions to somewhat close problems like these: One, Two, Three, Four, Five, Six, Seven, Eight, Nine, and they still have no reasonable solutions to them, only those that involve some supercomplex activities and anyway not giving a needed result.

So from my point of view as a business owner it should be something like this: there is a root user who can do everything. He can create admins and define access rights for them, for example in that very sudoers file. Then it’s his decision whether to give access to an admin to the sudoers file itself and any of the folders and commands of his choice. For example an admin could be able to run any command in the system except “reboot” and “visudo” and he can access all files and folders except /etc/sudoers and say /var/www/private_folder even WITH sudo privileges invoked (meaning he can’t even copy those files, overwrite them, chmod and chown them and so on, i.e. access them with any command).

That would immediately make the whole system administration A LOT more easier and logical, eliminating the need for complex solutions like chroot jails, separate bash environments, splitting servers into virtual machines, using containers and so on. And it’s so simple, a matter of a couple of conditions in the code, if I understand it correctly from a developer’s perspective. Also, I want to be in control of my VPS, not having to trust any other third person believing he/she won’t steal my information and/or destroy my whole system either by making a mistake or intentionally and basically it can be considered as a serious security vulnerability from a certain point of view.

This seems so obvious and logical for me, that I was really discouraged and embarrassed that it’s really isn’t like that in Linux. Maybe 20 years ago when Linux was created it was enough to have only a root and sudoers and the rest of users to accomplish tasks they had at that time, but today everything goes a bit different way already and that archaic approach is not usable anymore.

Of course I realize I can understand something wrong and there is a strong reason why it has to be as it is, then please let me know why is it so and what is a correct and easy way of solving my problem described above without a need to build a behemoth on my VPS or manually administering it all the time by myself. After all it should be user-friendly, right? Now it’s not.

On the other hand if there is no such a solution, then I would really be willing to even pay someone who could implement some kind of a patch or a package that will allow to solve this problem.

Run docker as not sudoers

I have on my ubuntu instance a group of non-sudoers (“deploy” group). In order, to enable them to use docker I have to change the permission of “/var/run/docker.sock” file to chgrp deploy /var/run/docker.sock and chmod 770 /var/run/docker.sock.

Is this approach considered as security blunder, is there any other better approach?

Why is sudoers NOPASSWD option applying the exception to ROOT instead of specified user?

/etc/sudoers:

# This file MUST be edited with the 'visudo' command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # Defaults        env_reset Defaults        mail_badpass Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"  # Host alias specification  # User alias specification  # Cmnd alias specification  # User privilege specification root    ALL=(ALL:ALL) ALL  # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL  # Allow members of group sudo to execute any command %sudo   ALL=(ALL:ALL) ALL  # See sudoers(5) for more information on "#include" directives:  #includedir /etc/sudoers.d  h ALL=NOPASSWD: /usr/bin/brightlight -i 20 -f /sys/class/backlight/amdgpu_bl0 

But doing the command still gives me a permission error.

h@pop-os:~$   brightlight -i 20 -f /sys/class/backlight/amdgpu_bl0 brightlight: could not open "brightness" file: Permission denied 

Also

h@pop-os:~$   sudo -l Matching Defaults entries for h on pop-os:     env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin  User h may run the following commands on pop-os:     (ALL : ALL) ALL     (root) NOPASSWD: /usr/bin/brightlight -i 20 -f /sys/class/backlight/amdgpu_bl0 

Things I have tried:

  • Rebooting
  • Creating a file in /etc/sudoers.d/brightlight with last line of config above

EDIT: Fixed, you need to add sudo, and it won’t prompt you for a password

sudoers command as a different user

I regularly need to drop a postres database and recreate it. It has to be done as postgres user as following:

$   sudo -u postres dropdb my_database  

I thought of adding sudoers rules for not being asked a password. Usually I proceed by creating a file in /etc/sudoers.d/ with a rule like this one:

Cmnd_Alias DROP_DB = /bin/bash -l -c dropdb*, /usr/bin/dropdb* emilio ALL = NOPASSWD: DROP_DB 

But in this use case, I need to run the command as postgres user and it doesn’t work.

What is the proper way to run a command as a different user without being asked a password?

Dialogs still ask for user password (instead of root’s) after adding rootpw to sudoers file

To add an extra layer of security I’m using the rootpw option in the sudoers file and while it works perfectly fine from the shell, when a specific command invokes the GUI version of “elevation”, only the user password will work in that case and not the root password. Do I need to change anything in PolicyKit config?

Kubuntu 18.10

I’d like the root password to be used everywhere, any ideas?

Using SUID program to avoid having entries in sudoers

Well, I’ve done a lot of reading and documentation around possible exploitation of sudoers files and SUID programs, but don’t have a deep enough knowledge to pick up the wisest possible solution for my problem.

We’re currently developping a Qt-based tool on Ubuntu for upgrade/rollback management of our main application.
So as you might have guessed, the said tool is making extensive use of apt install/purge and dpkg commands, that happen to be executable only with root privileges, which the tool does not have, as it is meant to be executed only within the limited-privileges user’s context.

To circumvent this limitation, the team has chosen the most straightforward solution : adding appropriate entries in the user’s sudoers file for the aforementioned commands.
BUT, as far as I know, this opens up a dangerous vulnerability in the system, as an attacker who would gain only limited access to the machine might then remove important components of the underlying linux system (systemd for instance), thus making the system crash.


As I’m the only cybersecurity engineer in the team, I’m trying to find the safest and most recommended way to mitigate this flaw, but so far could think of only one alternative : turning the upgrade tool into a SUID program.
The thing is : SUID programs have a nefarious reputation when it comes to privilege escalation vulnerabilities they might expose on the target system (see here for a checklist of all the considerations to implement in order not to mess up everything when writing a SUID program).

The question is : is going through this painful process really worth it ?
Is there any other way we could safely use apt/dpkg commands without all the hassle of SUID implementation, and without making the upgrade tool run with superuser mode ?

Note: a lot of questions on stackexchange cover SUID related concerns, but none actually discusses the specific usecase we’re dealing with.