Discussion on:

Security tools should be designed for security

So Ubuntu tries the old "two wrongs make a right" approach to security.

I've been using systems with superuser access since 1978 (DG AOS had the concept, too) and (touch wood) have yet to experience a break-in through that vector.

Unix's default behavior of changing the prompt for root access helps to remind you that you should press Ctrl+D at your earliest convenience. I also change the text color so it really stands out.

Using only sudo, you can't do anything that requires context to be maintained between commands, nor can you access shell aliases for either the root user or the logged in user. With su you get a shell context, and the aliases for root.

On Ubuntu, can you execute:

sudo sh

?

sudo cat, sudo su.. mwahahahahaa

In ubuntu, they even make mention of it on many of the common help guides.

It's the way I generally go about doing sys admin stuff on my laptop.

An admin terminal session is possible via the command "sudo bash".
I guess that would be about the same.

Why do you think it should be bash instead of sh?

sudo -s

This article's main point is completely rediculous. Using pam you can limit su to wheel by putting:
auth required pam_wheel.so use_uid

in pam.d/su. If you're not using pam on linux then you have bigger problems to worry about than non-wheel users using su.

It is a quick way to get a working desktop up when you don't need much security.

I don't put it on servers, at least when it's my choice to make. I do have a few clients who insist. They know I'm not crazy about it but I do help them with their projects.

All that said, it was a good article and I too don't like sudo on systems that are meant to be secure and safe.

I was pleasantly surprised to see a console based install wizard when I look at it. I wouldn't be using the workstation builds but the server default settings may be more sane (though, why youd us Ubuntu server instead of Debian.. I don't know).

The only reason to use Ubuntu server instead of Debian, as far as I can tell, is branding.

Thank you. You have killed several mysteries with one stone.

I am Ozymandias, Slayer of Mysteries. Look on my works, ye mighty, and, err, be unimpressed. Hah!

Funny, I didn't know you cavorted around the house in purple and gold tights...

/

A top quality (as always) article from you Chad, but I don't remember ever seeing a group wheel, so I looked in /etc/group (Debian system) and sure enough, it doesn't appear.

Am I missing something, or is wheel something that is built into the kernel, that is not a normal group?

Or is it, as Debian is the mother of Ubuntu, it doesn't use that group either?

Certainly, I use su all the time in Debian, so it's definitely implemented. But how?

Debian doesn't have the wheel group by default. You have to add it, then configure pam to use it to work around the GNU su limitation. It's kind of a dirty hack, but it works if you want to emulate proper su behavior.

I'll investigate further.

is what I use when I need to do some administrative work and don't want to write sudo all the time.

So I find sudo as implemented by Ubuntu a security problem instead of a solution, since the user's password alone can provide root access.

There is nothing wrong with sudo. sudo is a useful and secure tool for privilege escalation. The problem is that Ubuntu makes defangs sudo and makes it pointless, which is just as bad if not worse than Stallman imposing his vision of utopia on su.

is a fringe radical.
he's ok with that.

no need for me to mention my opinion of the article for you.
You know I agree with you on it.

Well I do not normally respond to articles but this one has me concerned.
su is not a SECURITY tool. It is a utility to allow the changing of identities. The command is Switch User and the default user is root.
su is available in Debian and Ubuntu but does not have a default of root.
To control who is permitted to become root the group wheel is used in BSD implementations. Therefore a user must log in and if they are in the wheel group then they are permitted to switch to the root identity.
sudo further extends this permissions thing by not having a root password and thus only those persons who are in the admin group or who have been granted limited permissions using the sudoers file are permitted to run system commands and utilities.
This is overkill on a desktop system but in a server it is important to control who can do what. As you pointed out an unhappy sysadmin can change the root password and lock out everyone. However using sudo that person would have to change the password for everyone in the group.
A sysadmin will keep his/her password to them selves however the root password becomes a none issue when it is the same on every system at the location and tends to be passed around by the responsible people. Those same people do not share their account passwords with the rest of the IT staff.

So IMHO su is NOT a security tool, it is a convenience for sysadmins. sudo is a tool to provide a granular control mechanism for system administrator programs and utilities.

*sigh*

*This* is what sudo is intended to avoid:

Here's a trivial way that a hacker or virus programmer could easily do an end-run around Unix privilege separation:

$ cd ~
$ echo "echo I just did something as root" > ls
$ sed -i 's/PATH.*/PATH=~/' .bash_profile
$ logout
[log back in]
$ su
Password:
# ls
I just did something as root
#

Of course, you *could* use `su -` all the time, but you just have to be lazy that one time...

The entire point of sudo is to force the user to only run the bare minimum of programs as root. Just like secure programming requires that privilege escalation should be done infrequently (if at all) and as briefly as possible. Sudo also allows an administrator (computers can be used by more than one person, didn't you know?) to control which commands are allowed to be run as root, and which users are allowed to do so.

with end user password for ALL system admin sudo is most definitely less secure.
and that is the Cannonical sin for all variants of their distro.

The article addresses using sudo as a complete, generic su replacement -- not using sudo as it was intended, as a way to provide limited administrative capabilities to a particular user account. You've addressed the matter of how using sudo properly can be useful for security, and not the topic discussed in the article.

(edit: typo)

The entire argument against sudo-instead-of-su assumes the following:

1. You're using Ubuntu for a task other than a workstation, or your workstation has remote access via ssh enabled through the (separate, usually) firewall (really, who has their workstation connected directly to the internet?).

2. That brute-forcing the password is a worthwhile endeavour for an attacker.

3. That you can't mitigate the brute-forcing of a user's password.

My argument is that unless the *user's* password is brute-forced, sudo is more secure than su. The only time I've ever seen a user's password get brute-forced is when the user's password is spectacularly stupid, like when the u/p is mike/mike2010. The only time random internet hackers ever make a concerted effort against a password is when they know the username, and more importantly, that they know that username leads to superuser access; ie: root.

Then, the author of this article makes the assumption that sudo is only for the weak-minded fools who are too lazy or distracted or otherwise forget to hit Ctrl-D when they're finished doing whatever they need to do as root. This however, basically describes 95% of system administrators. Which is *exactly* why sudo was created in the first place. And molly-guard, for that matter. Humans make mistakes. Humans who are good at their jobs and professional about it make somewhat fewer mistakes. But stupidity like using the 'ls' command as root can be pretty much expected.

The fact of the matter is that by removing the root account, and forcing the end-user to type in their password for the things that require superuser access, you're actually increasing the security of the system. Especially on workstations that are protected by NAT routers, which is pretty much the target market for Ubuntu.

If Ubuntu is failing at security somehow by doing this, it's only because they allow stupid passwords (well, they almost do - you can't use your username as your password, but mike/mike2010 is still possible) and they don't have something like fail2ban installed by default. These two features effectively snuff out any hope that attackers might have to brute-forcing passwords. If they can manage to guess the username, that is. Most brute-force password attacks are really lame and are only intended to find the easiest possible passwords. Hackers generally don't spend a lot of time on these kinds of attacks because other vulnerabilities are much faster and easier to take advantage of. Like say, the trivial virus/worm attack I just mentioned.

> The entire argument against sudo-instead-of-su assumes the following: 1. You're using Ubuntu for a task other than a workstation, or your workstation has remote access via ssh enabled through the (separate, usually) firewall (really, who has their workstation connected directly to the internet?). 2. That brute-forcing the password is a worthwhile endeavour for an attacker. 3. That you can't mitigate the brute-forcing of a user's password. My argument is that unless the *user's* password is brute-forced, sudo is more secure than su.

I still don't see how sudo is more The only time I've ever seen a user's password get brute-forced is when the user's password is spectacularly stupid, like when the u/p is mike/mike2010. The only time random internet hackers ever make a concerted effort against a password is when they know the username, and more importantly, that they know that username leads to superuser access; ie: root. Then, the author of this article makes the assumption that sudo is only for the weak-minded fools who are too lazy or distracted or otherwise forget to hit Ctrl-D when they're finished doing whatever they need to do as root. This however, basically describes 95% of system administrators. Which is *exactly* why sudo was created in the first place. The fact of the matter is that by removing the root account, and forcing the end-user to type in their password for the things that require superuser access, you're actually increasing the security of the system. Especially on workstations that are protected by NAT routers, which is pretty much the target market for Ubuntu. These two features effectively snuff out any hope that attackers might have to brute-forcing passwords. Most brute-force password attacks are really lame and are only intended to find the easiest possible passwords. Hackers generally don't spend a lot of time on these kinds of attacks because other vulnerabilities are much faster and easier to take advantage of. Like say, the trivial virus/worm attack I just mentioned.

1. You're misusing the term "hacker".

2. You should not ignore a blatant and obvious security vulnerability just because another vulnerability is more blatant and obvious.

3. Viruses and worms generally require direct user help to execute on non-Microsoft OSes.

4. Your "worm" attack requires as much access to the system as unauthorized use of sudo requires on Ubuntu, and it does less. That's not much of an argument for the superiority of sudo for security purposes.

5. You're ignoring the fact that sudo is much more susceptible to potential security vulnerabilities than su itself.

By the way, your ls "worm" wouldn't work on my FreeBSD laptop, because the path is changed to that of the target user ID when using su to elevate privileges. The vulnerability you would exploit isn't a problem with su -- it's a problem with GNU su. Just thought I'd mention.

Anyway, you seem to want to assume that nobody uses Ubuntu outside of workstation deployments inside a corporate network, which I find an unlikely restriction.

Why would you want to deploy Ubuntu on a server, when really it's just a pretty version of Debian? Who needs X on a server? Running X is a security vulnerability in itself, nevermind a massive resource hog.

That aside, why run an SSH daemon on a workstation/laptop at all? In your example of a corporate VPN through SSH, is the *laptop* the VPN server? No, that's brain damaged.

Also, if the end user has a stupid password, what's stopping said user from setting the root password to be the same as the user password? A systems administrator who also shut off the SSH daemon (if it was ever running by default to begin with) and any other servers on the laptop. Who then ran nmap against the laptop to make sure. And who probably set the password to something harder and gave the user a lecture about what happens to people who use bad passwords.

The fact of the matter is, that should an attacker ever get shell access of any kind (even as user "nobody"), it's pretty much game over. If they really cared to get root access, local (offline, as you say) brute forcing of the password is very fast through 'su', which *has* no tarpitting or lock-out ability. These days, attackers are mostly interested in nothing more than a CPU on an IP address, from which they run highly profitable phishing and spam attacks. If they're interested in corporate espionage, then it's all about attacking the internal network from that one vulnerable laptop (at any level of access). If there were any data on the laptop worth getting, it wouldn't be saved with read-only permissions for the "root" user, it would all be owned by the primary user. Which the attacker already has the password for, apparently.

So really, the difference between su and sudo is all about what access that user has to his own system. And whether or not he totally screws up the configuration on a regular basis.

By the way, I know the pedantic difference between the word "hacker" and "cracker". The people who cared about the original abuse of the term some 20 years ago have ceased to care, and so should you. Unless you want to keep looking like a pedantic noob.

"Why would you want to deploy Ubuntu on a server"

Canonical also produces Ubuntu Server Edition which does not apear to have X. Personally, I'd go with debian but if one wants Ubuntu Server, it exists.

"why run an SSH daemon on a workstation/laptop at all?"

- remote administration
- remote software use (both cli and gui)
- transfer of files to the workstation
- tunneling of unencrypted protocols
- provide secure network shares (eg. sshfs)
- provide secondary display/input when working with display drivers (I wouldn't build a workstation without ssh after that one)

(yes, at home, my workstation is my vpn server so "provide vpn" also applies)

"Also, if the end user has a stupid password, what's stopping said user from setting the root password to be the same as the user password? "

That doesn't mean we should promote insecure practice; especially when the better practice is just as easy. Someone's only going to rob the bank anyway so we should just leave all the bags of money on the front steps; it's easier that way after all.

What really scares me is the Linux Journal article "make sudo behave like Ubuntu on other distributions". I expect it to shortly be followed up by an article on how to make mammals retract there legs and return to the water or some similar self induced devolution.

"If they really cared to get root access, local (offline, as you say) brute forcing of the password is very fast through 'su', which *has* no tarpitting or lock-out ability."

If someone is that serious about getting root access, are we already not dealing with a targeted attack? Would they have gotten passwd/shadow files if the user account they breached didn't have a weak password? If they are cracking the passwords offline, wouldn't they use a specific cracking tool like John rather than reconstruct a duplicate lab system so they can run sucrack?

"By the way, I know the pedantic difference between the word "hacker" and "cracker". The people who cared about the original abuse of the term some 20 years ago have ceased to care, and so should you. Unless you want to keep looking like a pedantic noob."

Talks at every hacker related conference each year since those "20 years ago" would seem to indicate that people do still care about the use of the title and correcting the public misconception of it. I thought the single line pointing out your incorrect use was a rather civil inclusion. Given your admitted knowing the difference, would it have been that hard to use the correct term "cracker" where what you meant was a cracker; or ideally "criminal" when what you meant was criminal intent?