Difference of su -c and sudo?

[Crawdad]

Hi all,

I apologize if I'm posting this in the wrong section. Please move it to the appropriate section if needed.

Anyway, during my web browsing about stuff to fix on Fedora I come across some commands that start with su -c, mainly when installing stuff.

So, as the topic title goes, I was wondering what the difference(s) is (/are) between using su -c and sudo. I've tried using sudo with no visible problems.

Thanks in advance.

[Gareth Jones]

Both achieve the same basic task – to run a command with the privileges of another user, usually and defaulting to root.

su asks for the root password, whereas sudo will ask for your own password (as long as you are in the /etc/sudoers file, or a member of the wheel group), so the mechanism for controlling who gets access is different. With su it's based primarily on whether you know the appropriate password, whereas with sudo it's primarily based on configuration files and your user's existing privileges.

sudo also has a nicer command-line syntax, because su -c requires the command to run to be a single argument. This in turn can lead to complications with quotes and shell escape sequences if you're not careful.

[jpollard]

sudo has the ability to prevent a user authorized to perform actions to only those authorized actions. This is controlled by requiring the users password rather than the root password

su provides unlimited access, and requires the user to know the root password.

[stevea]

They are very different at a technical level, but as Gareth says they are used for mostly the same purpose.

Sudo authenticates the user against a list of commands and then executes that command with privilege.
'su' creates a new session (comparable to a new login), typically as root. This uses PAM and a startup shell, and potentially the root's startup shell contexts, and impacts process inheritance and controlling terminals.

sudo is more lightweight than su (takes less resources to execute). sudo is potentially more subject to exploit, however sudo has been around and tested for decades - not a big worry.

[Crawdad]

Thanks, guys! Now it's clear. So I guess I'd still continue to use sudo without having to worry too much if I'm doing something wrong.

Originally Posted by stevea

sudo is potentially more subject to exploit, however sudo has been around and tested for decades - not a big worry.

Hi Stevea, I think you meant su for the former?

[RupertPupkin]

Originally Posted by Crawdad

I think you meant su for the former?

Perhaps not. There are easy ways to get full root access from sudo, even when the user is restricted to simple commands like 'more'. On modern Linux systems those sorts of tricks have been pretty much eliminated (or so I've heard), but not on commercial UNIX systems. I know because I've used those tricks myself on Solaris and HP-UX.

That's the potential problem with sudo - it can give a false sense of security by thinking that untrusted users won't be able to get full root access. In contrast, su assumes the user is trusted enough to have root access from the start, so there are less surprises than with sudo.

[stevea]

Originally Posted by RupertPupkin

Perhaps not. There are easy ways to get full root access from sudo, even when the user is restricted to simple commands like 'more'. On modern Linux systems those sorts of tricks have been pretty much eliminated (or so I've heard), but not on commercial UNIX systems. I know because I've used those tricks myself on Solaris and HP-UX.

That's the potential problem with sudo - it can give a false sense of security by thinking that untrusted users won't be able to get full root access. In contrast, su assumes the user is trusted enough to have root access from the start, so there are less surprises than with sudo.

Yes this is exactly right.

su is safer as it uses the standard session creation authentication. It's just as safe as giving access to a login prompt.

sudo is not as safe for exactly the reasons RP cites, plus a few other potential exploits. Still sudo has been around for decades, most of the true evil has been beaten out of its implementation, and it can be used with relative safety. Still when a program can be directed to exec another it opens a hole in sudo-s command restriction feature.


If you give a good sudoer access to ALL commands, then it's more like 'su root -c ...', except there is the additional exploit potential of a badguy messing with setuid binary or modification of the sudoer config file or it's dependent libraries or .... . Those additional exploits are the ones that have been largely removed.by design.

[Crawdad]

Great info Thanks! Please do share more if there's still stuff to share.

[Gareth Jones]

I would add that the exploits involving sudo are not really flaws in sudo or its implementation. If sudo is configured to always refuse a user, that user is not going to get root access, as opposed to with su, where as long as they have the current password, they can (unless you do clever stuff with su's execute permissions with ACLs etc.).

The problem is that sudo gives a false sense of security by allowing execution of specific commands to specific users (Fedora doesn't do this by default – it's up to you to do so if you want). The problem here is that such commands must be written with that restricted usage in mind, just as with suid programs (e.g. login, su and sudo) – any program which itself can run other programs, or which isn't specially written with security in mind, could be used to gain more general root privileges if allowed by sudo. But this is true of any method of allowing an unprivileged user access to that command with privileges.

[stevea]

Originally Posted by Gareth Jones

I would add that the exploits involving sudo are not really flaws in sudo or its implementation. If sudo is configured to always refuse a user, that user is not going to get root access, as opposed to with su, where as long as they have the current password, they can (unless you do clever stuff with su's execute permissions with ACLs etc.).

That *may* be true currently (that sudo doesn't contain implementation flaws) but IIRC long ago sudo did have bugs that caused the potential for a few clever exploits. I mean is *seems* simple for the privileged sudo program to call system("some string") if and only if the first element of the string matches an allowed command, but evil-doers can play tricks with the shell IFS character and line terminators and parameter expansions and the shell selection and cause unexpected things to execute. You can chroot to someplace evil and then maybe execute a fake "/bin/ls" even tho' the path it rooted.

I don't want to harp on it as I rather like the former FedoraForum user 'bee', but he got a sudo-like program into the repos called 'beesu'. and I've posted before that it has some security holes based on it's internal string processing (search the forum if you care). So it really pays dividends to use the long-established, reliable and well-honed security tools like sudo and NOT try the latest one-off flavor.

Gareth is right tho' that exploits to modifying the sudo config or 'jack' the setuid binary are not directly faults of sudo design.

The problem is that sudo gives a false sense of security by allowing execution of specific commands to specific users (Fedora doesn't do this by default – it's up to you to do so if you want). The problem here is that such commands must be written with that restricted usage in mind, just as with suid programs (e.g. login, su and sudo) – any program which itself can run other programs, or which isn't specially written with security in mind, could be used to gain more general root privileges if allowed by sudo. But this is true of any method of allowing an unprivileged user access to that command with privileges.

Minor objection Gareth, thats A problem, not THE problem. The very existence of a setuid binary is a security headache. In case the OP doesn't understand when a program binary is owned by root and has it's setuid permission set (man chmod for "+s") then it executes with root privilege regardless of who starts the process.

Currently (F16) there aren't very many setuid root owned programs left. I have this list ....

-rwsr-xr-x 1 root root      33944 Sep 22  2011 /bin/fusermount
-rwsr-xr-x 1 root root      90640 Apr 17 09:38 /bin/mount
-rwsr-xr-x 1 root root      34904 Mar 26 06:31 /bin/su
-rwsr-xr-x 1 root root      60960 Apr 17 09:38 /bin/umount
-rwsr-xr-x 1 root root     109088 Mar 16 11:15 /sbin/mount.nfs
-rwsr-xr-x 1 root root      10576 Jan 31 12:35 /sbin/pam_timestamp_check
-rwsr-xr-x 1 root root      35520 Jan 31 12:35 /sbin/unix_chkpwd
-rwsr-xr-x 1 root root      53792 Apr 20 05:03 /usr/bin/at
-rwsr-xr-x 1 root root      58128 Feb 13 06:18 /usr/bin/chage
-rws--x--x 1 root root      23448 Apr 17 09:38 /usr/bin/chfn
-rws--x--x 1 root root      19288 Apr 17 09:38 /usr/bin/chsh
-rwsr-sr-x 1 root root      55720 Oct 26  2011 /usr/bin/crontab
-rwsr-xr-x 1 root root      67384 Feb 13 06:18 /usr/bin/gpasswd
-rwsr-xr-x 1 root root      36144 Feb 13 06:18 /usr/bin/newgrp
-rwsr-xr-x 1 root root      35720 Feb  8  2011 /usr/bin/passwd
-rwsr-xr-x 1 root root      31752 Oct 26  2011 /usr/bin/pkexec
---s--x--- 1 root stapusr  158568 Feb 22 14:15 /usr/bin/staprun
---s--x--x 2 root root      78432 Jan 26 10:22 /usr/bin/sudo
---s--x--x 2 root root      78432 Jan 26 10:22 /usr/bin/sudoedit
-rws--x--x 1 root root    1965224 Mar 27 01:13 /usr/bin/Xorg
-rws--x--x 1 root root      46632 Oct  3  2011 /usr/sbin/userhelper
-rwsr-xr-x 1 root root       9144 Mar 12 14:17 /usr/sbin/usernetctl

Some of these like chsh has simple functions and we hope they are well enough written to avoid exploits. Some like Xorg are huge and hairy and I doubt if anyone can attest there are no exploits. Some like 'visudo' is complex and single function and should be eliminated (we can let the admin 'su -c "vi /etc/sudoer.d/foo.conf"').

So there are two fundamental flaws in all this.

First Linux has ~4 separate security models in place, basic(has some other name), POSIX, CAPABILITIES and SELinux. These POSIX setuid programs give way way too much power to the executable process - it is effectively root=king-of-the-world. We cold remove all power from root using more fine-grains secutiy models like CAPABILITIES and/or SELINUX. There has been some effort to use capabilities to control a few programs that just need restrictive privileges.
getcap filename produces ....

/bin/ping = cap_net_raw+ep
/bin/ping6 = cap_net_raw+ep
/usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep
/usr/sbin/seunshare = cap_dac_override,cap_fowner,cap_setuid,cap_setpcap,cap_sys_admin,cap_sys_nice+ep
/usr/sbin/dumpcap = cap_net_admin,cap_net_raw+eip
/usr/sbin/suexec = cap_dac_override,cap_setgid,cap_setuid+ep

SELinux has extremely fine-grained control and we could add user 'stevea' to a user context group where he has access to a set of privileged utilities and not others. Somewhat like sudo but in the kernel and very strong and reliable. However writing policy for this was complex, tedious and detailed work.

Maybe in the future we'll have no root at all, and a super-sudo based on fine-grained MAC (mandatory access control) but it's not in sight yet.

The other problem is that all this security is 'intra-system' and often based on security models that most correctly apply to 1980s time-sharing systems. so if your 1980 campus VAX has 50 user accounts, and someone gains 'root' privilege - then they can pillage all 50 user accounts. That is NOT the situation for PCs today. I constantly hear "oh - what if root is using a browser ,email, wget, .. (other Inet tool) and it somehow installs some privileged exploit !". So how is this scenario any worse than if I'm using the Inet tool and it somehow installs an unprivileged exploit for my account ?!!? Once my banking&investment accounts and my work accounts are gone - the rest is pointless. All the goodies are in ~one account o a PC, not 50. My point is that root priv exploits only give away a tiny amount more value than my account privs. You can't protect a PERSONAL computer just by hardening the privileged software or root accounts; that is a necessary but grossly insufficient goal. You have to harden the user accounts too. If I logged in as root every day, all day, it would be a negligible increase in exploit potential of my systems.

So why are we so anal about keeping users away from privileged software ?
/We want to prevent PC user-admins from making mistakes - but ultimately that's impossible.
/We want to prevent "the kids" or semi-trusted users from making mistakes or executing pranks.
/If you leave an unattended terminal at a command prompt we can prevent an evil-doer from causing a system disaster - but they can still install an unprivileged exploit and steal all my money. So this is pointless.
/If your laptop is stolen of even your desktops - you want all the important info to be inaccessible - but this requires encryption+sepaate keys, at least of account info and emails and similar personal info and has little to do with privileges.


Here's one interesting opinion on administrative tool security,
https://plus.google.com/u/0/10215069...ts/1vyfmNCYpi5

Whoever moron thought that it's "good security" to require the root password for everyday things like this is mentally diseased. - Linus Torvalds on OpenSuse

[dd_wizard]

There are a few other setuid programs in F17, but perhaps you restricted your search to $PATH? All the ones I found in F17 were in /usr though:

$ sudo find / -perm /4000 | sort
/usr/bin/Xorg
/usr/bin/at
/usr/bin/chage
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/crontab
/usr/bin/fusermount
/usr/bin/gpasswd
/usr/bin/ksu
/usr/bin/mount
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/pkexec
/usr/bin/su
/usr/bin/sudo
/usr/bin/sudoedit
/usr/bin/umount
/usr/lib64/dbus-1/dbus-daemon-launch-helper
/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache
/usr/libexec/polkit-1/polkit-agent-helper-1
/usr/libexec/pulse/proximity-helper
/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper
/usr/sbin/mount.nfs
/usr/sbin/pam_timestamp_check
/usr/sbin/seunshare
/usr/sbin/unix_chkpwd
/usr/sbin/userhelper
/usr/sbin/usernetctl
/usr/share/BackupPC/sbin/BackupPC_Admin

dd_wizard

[jpollard]

ksu has security vulnerablilities - it is the Kerberos equivalent to su, but the Kerberos libraries are NOT designed to operate in a setuid environment. So ksu attempts to re-implement (poorly) those functions that were known to be problems... The best thing to do is delete it. This has been the recommended practice throughout the DoD HPC environment.

If you want the equivalent (without the headaches) use krsh to local host.

[Gareth Jones]

Originally Posted by stevea

That *may* be true currently (that sudo doesn't contain implementation flaws) but IIRC long ago sudo did have bugs that caused the potential for a few clever exploits. I mean is *seems* simple for the privileged sudo program to call system("some string") if and only if the first element of the string matches an allowed command, but evil-doers can play tricks with the shell IFS character and line terminators and parameter expansions and the shell selection and cause unexpected things to execute.

Good point, that makes sense. However, it still comes from a false sense of security in relying on sudo to filter commands, rather than sudo allowing something that su would prevent.

Minor objection Gareth, thats A problem, not THE problem. The very existence of a setuid binary is a security headache.

... or indeed the existence of an all-powerful root account, as you get to later. It'd be nice to move away from that, but the traditional Unix security model has one thing massively in its favour: it's very simple. Making the security model more complex potentially allows for better security, but can also just give people more rope to hang themselves, so whatever root-less security model eventually becomes the normal, it'd better be reasonably elegant. SELinux and capabilities as they currently exist are unfortunately not there yet.

You have to harden the user accounts too.

Agreed.

/We want to prevent PC user-admins from making mistakes - but ultimately that's impossible.

But we can help. Being asked for a password makes most people stop and think. Mistakes slip through, but the number of times I've typed rm in the wrong terminal and been saved by permissions is not as small as I'd like.

/If your laptop is stolen of even your desktops - you want all the important info to be inaccessible - but this requires encryption+sepaate keys, at least of account info and emails and similar personal info and has little to do with privileges.

Yes, encryption is as basic to security as password accounts. Unfortunately, trying to explain that to most people just gets you a blank expression...

Another issue is that, if my browser is exploited, ultimately I can clean out my home directory (nuke everything outside Documents, Music etc., check my personal files and/or restore from back-up) without having to completely reinstall the system, as I would if I was logged in as root at the time. How much of a saving that is is a matter of taste I suppose...