How to remove sudo capabilities of a non-root user?

[Neo_78]

According to the documentation, FatDog uses GtkSu "whenever an application running in non-privileged mode requires root access". Which means a non-root user can temporarily execute a command or program as root using the sudo or su command.

Is there a way to exclude a non-root user from this form of privilege escalation, so that su or sudo cannot be used?

In the user management interface under "groups" I could not find a su or sudo group.

Deleting the su command from the bin folder seems to do the trick but is not a very elegant solution as it will throw a error when the sudo command is used.

Also, is there an explanation of the different system groups in the user management interface available somewhere? The documentation only mentions the base group requirements for a functional non-root user.

[rockedge]

Hello Neo_78,
remove the user from the sudo group

try:

Code: Select all

sudo deluser USERNAME sudo

there are other ways to do it, most important is remove the user from the sudo group CAREFULLY!

[step]

I think, you asked how to restrict non-root users from using su to run as root. The version of su that is installed in Fatdog64 can be configured using /etc/login.defs. Specifically, the manual mentions

SU_WHEEL_ONLY (boolean)
If yes, the user must be listed as a member of the first gid 0 group in /etc/group (called root on most Linux systems) to be able to su to uid 0 accounts. If the
group doesn't exist or is empty, no one will be able to su to uid 0.

which should provide a way to avoid priviledge escalation. I did not test it.

While there is a sudo command in Fatdog64, it's a stub that eventually runs su. Hence there is no sudo group and even if there was one it wouldn't matter.

For the full su manual, please load the devx.sfs, which includes all manuals. I wanted to add a link to an online manual for su but all those I found describe a different version that has very little in common with Fatdog64's.

[Neo_78]

@rockedge FatDog does not appear to have a sudo group.

@step I am basically looking for a way to implement default behaviour of most Debian based distributions: When you create a new user, this user is not part of the sudo group. If you try to execute a command with sudo, an error will be displayed that the incident has been logged and that the user is not part of the sudo group. The user can optionally be added to the sudo group. In this way privilege escalation can be limited to specific users.

What would be the best way to achieve this in FatDog?

Where can I find the mentioned devx.sfs ?

[rockedge]

In KLV it's the wheel group, could be also so in FatDog. Sorry I'm not very familiar with the inner workings of the big guy.

[Neo_78]

There is a wheel group but it does not have any users assigned.

[dr__Dan]

Hi @Neo_78! The devx.sfs is in the repository, and easily downloaded and installed using the SFS Manager in Control Panel > System > SFS Manager. I think what step suggested, editing the /etc/login.defs file as described will accomplish what you want.

[jamesbond]

As @step says, Fatdog does not have sudo.
"sudo" in Fatdog is just a compatibility script to make foreign scripts (e.g. scripts written for Ubuntu or Arch or whatever) happy.
When run as root, the "sudo" script does nothing.
When run as any other user, "sudo" script will attempt to elevate privilege by running "su", a real binary.
The "sudo" script does not have the extensive management features (e.g. wheel group) that the real sudo has.

"su" in Fatdog is a busybox binary that does not respect login.defs. The only thing it respects is /etc/shells.
If you really want to get rid of "su", then you have two options:
- delete it
- or reduce its power, use "chmod 0755 /bin/su" (this will remove its suid bit and effectively make it impotent).

"gtksu" has a configuration file in /etc/gtksudoer. But this configuration file is used to "relax" gtksu's behaviour, not to tighten it. The default configuration (which is blank) is as tight as it can be, which is identical to "su". So if you don't like it, again, either delete it, or "chmod 0755 /usr/bin/gtksu").

Whichever you do, for all these to be __really__ effective, you have to remaster.

[Neo_78]

@dr__Dan thanks, I found devx_812.sfs in the respository. Stupid question, but once I have downloaded and enabled the repository via the SFS Manager, how do I access the manuals? Looking at /etc/login.defs and the mentioned "SU_WHEEL_ONLY" option: I am a bit unclear if the option description refers to the "root" group or the "wheel" group. By default only the root user is part of the root group, while the wheel group is empty. If I understand this correctly and I set the option to "yes", only non-root users that are specifically added to the "root" group will be able to escalate privileges using the su command? My intention is NOT to create a second root user with super powers but rather to selectively enable certain users to use su and others who are not capable of doing that. And if that's the correct interpretation, I assume that you would still have to delete gtksu to prevent privilege escalation.

So I guess the simplest way in the short run is to follow the suggestion of @jamesbond and delete or chmod su and gtksu to disable privilege escalation of non-root users entirely.

[Neo_78]

Update:

Deleting su will break the menu items listed under "Internet", which cannot be executed. So effectively the browsers cannot be started any longer.

Firefox will still start from the terminal but Chrome will throw the following error:

Code: Select all

google-chrome-spot
/usr/bin/run-as-spot: 61: exec: su: not found

So the the only option would be to chmod 0755 @jamesbond?

Or is there a way to run Chrome as "non-spot" (chrome or google-chrome from the terminal will return "command not found" errors)?

[jamesbond]

Update:

Deleting su will break the menu items listed under "Internet", which cannot be executed. So effectively the browsers cannot be started any longer.

If you delete "su" then "run-as-spot" will no longer work.
All browsers and many other network-programs run as spot, so they all will fail.
To avoid them from failing, you need to tell them to run as root (or whatever user that you're currently logged-in).

To do this, open Control Panel -> System -> Convert Spot Apps to Root Apps.

Or is there a way to run Chrome as "non-spot" (chrome or google-chrome from the terminal will return "command not found" errors)?

google-chrome-stable --no-sandbox

[Neo_78]

I am basically using root only to configure the system, install software and then use the created non-root user for normal operation @jamesbond. Even if you do not delete su, the browser will be executed as the respective non-root user and not spot. Is that expected?

So I am wondering if it's really the best approach to delete su as it seems to break some system functionality. Maybe there is a better way to configure the desired outcome in /etc/login.defs without creating a second root account?

[jamesbond]

Even if you do not delete su, the browser will be executed as the respective non-root user and not spot. Is that expected?

This is the default situation:
- If you are logged in as non-root user, the browser etc will run as the logged-in user, not as root.
- If you are logged in as root, the browser will be run as "spot".

After you run the conversion process (Control Panel -> System -> Convert Spot Apps to Root Apps)
- If you are logged in as non-root user, the browser etc will run as the logged-in user, not as root (same as before)
- If you are logged in as root, the browser will be run as root.

So I am wondering if it's really the best approach to delete su as it seems to break some system functionality.

You will have to decide this for yourself. Everybody's needs is different, and I don't want to pretend to know what it is that you want to achieve. Removing "su" or "chmodding" it are not the only options; there other things like using "capsh" and stuff which rufwoof would be the better person to ask / help.

Maybe there is a better way to configure the desired outcome in /etc/login.defs without creating a second root account?

Fatdog's standard login does not support /etc/login.defs.

If you need one that does, do this:
- delete /bin/login
- create a symlink from /bin/login-FULL to /bin/login (or just rename /bin/login-FULL to /bin/login)
This is the "login" program whose manpage is here.

But please now that this is NOT a common practice, so be prepared for breakage; and it's something that I HAVE NOT TRIED MYSELF, so if it does break - you will be on your own. If it doesn't break, then please report back, we'd like to hear your experience

[Neo_78]

Thanks @jamesbond. I am basically looking for a way to implement the behaviour of most Debian-based distributions: When you create a new non-root user and you try to use sudo or su, the attempt will be rejected and logged. Privilege escalation is only possible if that non-root user has been added specifically to the sudo / su group. So you have fine-grain control if a specific non-root user can or cannot escalate privileges. Not sure if that's possible?

I am not happy with gtksu but I also don't want to break a fat dog...

[rockedge]

@Neo_78 did you ever try the Void based distro's? Just use a installed sudo setup to do exactly what you can do in Ubuntu/Debian. I can imagine DebianDog builds can do sudo exactly. Can sudo be set up on a FatDog64? I have never tried to do it myself yet.

Then it's just a matter of configuration.

[jamesbond]

Thanks @jamesbond. I am basically looking for a way to implement the behaviour of most Debian-based distributions: When you create a new non-root user and you try to use sudo or su, the attempt will be rejected and logged. Privilege escalation is only possible if that non-root user has been added specifically to the sudo / su group. So you have fine-grain control if a specific non-root user can or cannot escalate privileges. Not sure if that's possible?

Debian has a lot more going behind it than just su and sudo

But anyway, on to your question: It is possible, but you will have to configuring / experiment with it yourself.

I told you previously that Fatdog's standard login does not have all the features, and you can use the "FULL" version of login by deleting /bin/login and replacing it with /bin/login-FULL (either by copying, or by symlinking). This "login-FULL" is the same login used by everybody else in the world.

Now, Fatdog's standard su also does not have all the features. You can use the "FULL" version of su in the same way - delete /bin/su, and replace it with /bin/su-FULL. Remember to chmod 4755 /bin/su-FULL because it is not suid by default.

And since you're doing this, you may as well use the FULL version of passwd too, just in case. Process is the same, delete /bin/passwd and replace it with /bin/passwd-FULL.

These "FULL" version of login, su, and passwd are the same versions used by Debian and everybody else, so you should be able to configure it the way you do it in other systems. It supports the "wheel" group, login.defs, securetty ... the usual stuff that you read about elsewhere.

But you will be on your own. Please do, however, record and share your experience here, so that in the future, other people who have similar needs to you, can learn from your experience.

As for sudo - we don't have sudo. So that's one insecurity loophole that you can cross off your mind.
Our compatibility "sudo" script uses "su", so if you have "secured" su, then you don't need to worry about it anymore.
But if you need the real sudo's functionalities, however, you will have to compile it yourself. We don't have it in gslapt.

I am not happy with gtksu but I also don't want to break a fat dog...

You can chmod 0755 /usr/bin/gtksu, just like what you did to su, to neuter its power.
Or you can just delete it.
Or you can just delete it and replace it with a symlink to /bin/false.
Or you can write a replacement script for gtksu that pops-up an error message.
So many possibilities.

[Neo_78]

@rockedge haven't had the time yet to test Void-based distributions. I am pretty happy with most stuff and configuration options that FatDog is offering so far. But I will give it a try as soon as I get a chance.

@jamesbond sounds like taking the fat dog for a walk to new frontiers... Excuse my ignorance but the mentioned FULL versions already ship with FatDog? Or would I have to manually copy those from the Debian repository? Disabling gtksu is probably a good first step without breaking any core functionality.

[JakeSFR]

Excuse my ignorance but the mentioned FULL versions already ship with FatDog?

Already there:

xscreenshot-20220204T235647.gif (24.17 KiB) Viewed 1374 times

Greetings!

[Neo_78]

@JakeSFR perfect, thanks!