# How to Limit su Command Access Using Linux Group Permissions

> Secure your Linux server by limiting su command access. Learn how to use Linux group permissions and dpkg-statoverride to restrict execution to authorized users.

- Repository: [IMTheNachoMan/How-To-Secure-A-Linux-Server](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server)
- Tags: how-to-guide
- Published: 2026-05-14

---

**The most secure way to limit access to the su command is by creating a dedicated Linux group, adding authorized users to it, and using dpkg-statoverride to restrict the /bin/su binary to mode 4750 so only group members can execute it.**

The `su` command allows any user to switch to another user identity, typically root, by leveraging its set-user-id (setuid) bit. According to the imthenachoman/How-To-Secure-A-Linux-Server repository, restricting this capability to a specific group significantly reduces your server's attack surface by preventing unauthorized privilege escalation attempts.

## Understanding the su Permission Model

The `/bin/su` binary ships with **setuid root permissions**, meaning it executes with root privileges regardless of which user invokes it. By default, this allows any account on the system to attempt authentication and potentially gain root access.

To restrict this capability, you must modify the binary's permissions to remove "others" execute access while retaining the setuid bit for a specific group. This transforms the permission mode from `4755` (setuid root, world-executable) to `4750` (setuid root, group-only executable).

## Step-by-Step Implementation

The following procedure targets Debian and Ubuntu systems using `dpkg-statoverride`, which ensures permission changes persist across package upgrades.

### Step 1: Create the suusers Group

First, establish a dedicated group for users permitted to use `su`:

```bash
sudo groupadd suusers

```

This creates the group definition in `/etc/group`.

### Step 2: Add Authorized Users to the Group

Add specific user accounts to the newly created group using `usermod`:

```bash
sudo usermod -a -G suusers alice
sudo usermod -a -G suusers bob

```

Repeat this command for every account requiring `su` access.

### Step 3: Restrict /bin/su with dpkg-statoverride

Apply the permission override to `/bin/su` using `dpkg-statoverride`. This command sets the ownership to `root:suusers` and mode to `4750`, as documented in the [README at line 901](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/master/README.md#L901):

```bash
sudo dpkg-statoverride --update --add root suusers 4750 /bin/su

```

This configuration ensures that only members of the `suusers` group can execute the binary, while maintaining the setuid root bit necessary for the command to function.

## Verifying the Configuration

Confirm the permission changes took effect by inspecting the binary:

```bash
ls -l /bin/su

```

You should observe output similar to:

```text
-rwsr-x--- 1 root suusers 123456 Jan  1 12:34 /bin/su

```

The `s` in the owner execute position indicates the setuid bit remains active, while the `r-x` for the group and `---` for others confirm the restriction.

To validate the security control, attempt to use `su` from an account not belonging to `suusers`:

```bash
su

```

The system should immediately return:

```text
su: Permission denied

```

## Summary

- **Create a dedicated group** (e.g., `suusers`) to explicitly define which accounts may escalate privileges.
- **Use `dpkg-statoverride`** on Debian/Ubuntu systems to set `/bin/su` to mode `4750` with `root:suusers` ownership, ensuring the change survives package upgrades.
- **Verify permissions** with `ls -l /bin/su` to confirm the setuid bit persists while world-execute access is revoked.
- **Test denial** by attempting `su` from unauthorized accounts to ensure the restriction functions correctly.

## Frequently Asked Questions

### What is the difference between restricting su and using sudo?

While both commands elevate privileges, `su` requires knowing the target user's password (typically root), whereas `sudo` validates the invoking user's password against policies in `/etc/sudoers`. Restricting `su` to a specific group adds a mandatory access control layer that `sudo` alone does not provide, ensuring only explicitly authorized accounts can attempt direct root authentication.

### Why use dpkg-statoverride instead of chmod?

The `dpkg-statoverride` command records the permission change in the package management database, preventing subsequent updates to the `util-linux` or `login` packages from reverting your security modifications to the default `4755` mode. Direct `chmod` changes would be lost during the next system update.

### Will this method work on RHEL, CentOS, or Fedora?

No, `dpkg-statoverride` is specific to Debian-based package management (DPKG). On Red Hat Enterprise Linux, CentOS Stream, or Fedora, you must use `chmod 4750 /bin/su` and `chown root:suusers /bin/su` directly, then configure the `rpm` permission database or use configuration management tools like Ansible to maintain the state across updates.

### How do I restore default su permissions if needed?

To revert the changes on Debian/Ubuntu systems, remove the statoverride entry:

```bash
sudo dpkg-statoverride --remove /bin/su

```

This restores the original package permissions (typically mode `4755` with `root:root` ownership), allowing any user to execute `su` again.