When comparing sudo su - with granular sudo permissions, we're essentially evaluating two security models:

# Full root access method
$ sudo su - 
# Password: [user_password]
# Now operating as root with full privileges

# Granular access method
$ sudo systemctl restart nginx
# Password: [user_password]
# Only executes specified command as root

The key logging difference becomes apparent in /var/log/auth.log:

# sudo su - entry
May 15 10:00:01 server sudo:  user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/su -

# Granular sudo entry
May 15 10:01:01 server sudo:  user : TTY=pts/0 ; PWD=/home/user ; COMMAND=/usr/bin/apt update

When configuring sudoers via visudo, these approaches demonstrate the contrast:

# Risky approach (allows full root shell)
user ALL=(ALL) ALL

# Better alternative (specific commands only)
user ALL=(root) /usr/bin/apt update, /usr/bin/systemctl restart nginx

# Worst practice (hidden full access)
user ALL=(ALL) NOPASSWD: ALL

For teams requiring elevated access:

• Implement sudo -i instead of sudo su - for clearer audit trails
• Configure session timeouts: Defaults timestamp_timeout=5 (5 minute window)
• Use sudo -l to review granted permissions

Legitimate use cases for sudo su - might include:

# When performing multiple administrative tasks in sequence
$ sudo su -
# root@server:~# apt update && apt upgrade -y
# root@server:~# systemctl restart affected-services

However, even this can be mitigated with:

$ sudo -- sh -c 'apt update && apt upgrade -y && systemctl restart services'

In Linux administration, granting root privileges always involves trade-offs between security and convenience. The sudo su - approach sits at the controversial intersection of these concerns:

# Common privilege escalation patterns
su -                     # Requires root password
sudo su -                # Requires user's sudo password
sudo -i                  # Alternative to sudo su -
sudo bash                # Another variant

When users default to sudo su -, system logs lose valuable context. Compare these scenarios:

# Good practice (traceable)
$ sudo apachectl restart
# Log shows: user=jdoe cmd=apachectl restart

# Problematic pattern
$ sudo su -
# root# apachectl restart
# Log shows only root activity

Instead of blanket sudo su - permissions, consider granular sudoers configurations:

# /etc/sudoers.d/webadmins
# Allow specific commands
%webadmins ALL=(root) /usr/bin/systemctl restart apache2, \
                               /usr/bin/vi /etc/apache2/sites-enabled/*

# Explicitly prevent shell access
Defaults !requiretty
Cmnd_Alias SHELLS = /bin/bash, /bin/sh, /bin/zsh
%webadmins !SHELLS

Consider these attack vectors enabled by unrestricted sudo su -:

• Compromised user credentials grant full root persistence
• Malicious insiders can cover their tracks
• Shared accounts make attribution impossible

For organizations requiring root access:

# Implement jump hosts with session recording
$ ssh -J jumphost.prod.internal production-server

# Use centralized privilege management like:
# - SELinux RBAC
# - SSSD integration with Active Directory
# - Hashicorp Boundary

The one valid use case for sudo su -:

# When direct root SSH is disabled (security best practice)
$ ssh admin@server
$ sudo su -  # Only for break-glass emergency access

Always accompany this with session monitoring tools like auditd or commercial equivalents.