Comments for Mihai's Weblog

Comment on Security issues with sudo by martinpitt

martinpitt — Mon, 20 Jul 2009 12:27:08 +0000

> The real question behind sudo is how do you download/execute from
> the web outside social engineering?

Exactly. We have already received complaints about not running downloaded .exe files by default (through wine). But I do my best to defend this behaviour.

Comment on Security issues with sudo by martinpitt

martinpitt — Mon, 20 Jul 2009 12:25:33 +0000

> I find (1) too extreme. It is harder to use if made right but
> that’s not even close no unusable.

Avoiding trojan horses will mean to disallow the user to execute _anything_ he can write to, i. e. anything from his home directory. That includes custom .desktop files, browser plugins, office documents (macros), scripts in ~/bin/, etc. This might be appropriate for some office environments, but most users would simply run away scared or disable this lockdown entirely.

> A proper gksu screen (and gksu the only method to get root
> access) with the proper information and clearly identifiable as
> such (no user application should be able to imitate its screen
> locking)

That would require a kernel mechanism like pressing SAK (SysRq+K), which cannot be intercepted by any user program. It’s certainly not an unreasonable thing to do, but I guess there is a reason why Windows abandoned that approach again (usability). This would be pretty much the only defence against trojans pretending to be gksu, if all applications which ask you for passwords behave the same.

However, all the fuss about protecting root is pretty much moot on a desktop machine anyway. The really interesting data lives in your home account (credit card numbers, cookies, emails, documents, etc.). That’s of course not an excuse to not protect the root user as far as possible, but nowaday’s OSes have to balance usability against lockdown. As windows firewalls and UAC, and also restrictive SELinux by default, spectacularly demonstrated, users will just turn off security mechanisms entirely if they get too much in the way.

My personal opinion is that desktops are much better off by protecting themselves from running trojan horses in the first place, for the reasons above. I. e. nothing that you download from browsers, email clients, etc. must be executable by default, and the kernel/desktop enforce that you can only run files which are marked executable. The only exception known to me are office documents, but OO.o already warns you about embedded macros and needs you to confirm that you want to run them.

Comment on Security issues with sudo by Muharem Hrnjadovic

Muharem Hrnjadovic — Mon, 20 Jul 2009 10:08:24 +0000

If you really think you’re onto something here, why not be constructive for a change and file a bug here https://bugs.launchpad.net/ubuntu/+source/sudo ?

Oh, and while you’re at it, please remember to mark it as a security vulnerability.

Thank you!

Comment on Security issues with sudo by Siggi

Siggi — Sun, 19 Jul 2009 23:29:50 +0000

You dont need a password to run su. Edit /etc/pam.d/su:
# Uncomment this if you want wheel members to be able to
# su without a password.
auth sufficient pam_wheel.so trust

Uncomment the above line and then everyone in the wheel group can do su without a password.

Comment on Security issues with sudo by TGM

TGM — Sun, 19 Jul 2009 21:52:26 +0000

I think it’s worth a mention that the way Ubuntu handles the root account (disable root, sudo from named admin account) is a better way, it’s moving the goalposts for attacks that try to bruteforce their way into root (‘root’ being the default account in Linux) by disabling root altogether, a bruteforce has to figure the username as well, making things harder.

The real question behind sudo is how do you download/execute from the web outside social engineering? Linux makes security breaches so much harder.

Comment on Security issues with sudo by unix user

unix user — Sun, 19 Jul 2009 16:58:33 +0000

I think the problem is the default configuration of Ubuntu, the unprivileged user must not be able to run all commands as root with sudo neither must be able to do this without any password.
The problem is in the default config of /etc/sodoers file, sudo is great to delegate SOME command to SOME users such a shutdown or synaptic, is not designed to replace entirely root or su.
Just my 2 cents.

Comment on Security issues with sudo by Rambo Tribble

Rambo Tribble — Sun, 19 Jul 2009 15:53:17 +0000

Thinking in browser-like terms, the possibility of substituting a local script for a system executable suggests the opportunity for password capture and forked processes, while still executing the command, as expected, in foreground.

However, if you allow someone to copy files to your machine, you’re toast any way you slice it. Sudo and most other security measures are reasonable within their context, which virtually always assumes a degree of physical security, either through lock and key or encryption. Hand your equipment to your attacker, or vice versa, and reasonable attempts at security are compromised by unreasonable conduct, not by intrinsic flaws to the security model.

Comment on Security issues with sudo by Mihai Varzaru

Mihai Varzaru — Sun, 19 Jul 2009 15:33:36 +0000

martin:
I find (1) too extreme. It is harder to use if made right but that’s not even close no unusable. Think at someone who hardly does any administrative task anymore (you probably won’t find many such linux users). The people that do need to protect their root account (like mixed server-desktop computers or the bank operations example above) might accept the extra inconvenience. A proper gksu screen (and gksu the only method to get root access) with the proper information and clearly identifiable as such (no user application should be able to imitate its screen locking) would be a reasonable solution for a somewhat educated (understands how a command looks) and willing to pay attention user. The user can also be helped to understand what he is running with warnings like “non system application” (easier to identify if the ~/home/bin application is run directly, harder if it is run indirectly (like a parameter, or a setting in a given as parameter config file); you can also do it with a fixed list: synaptic, users, etc).
Locking admin menus and making gksu special for the system (not taken from path) probably close the most common avenues of attack (common not because hackers think easier at them but because that’s how users usually get to root; some users might never use the uncommon usage patterns).
The reasonably paying attention user described above should not be as easy to fool by the random gksu screen (he has the minimal education to realize that is unexpected and can look at what he is actually running).
I am confident that the other methods to elevate privilege to root can be reasonable (reasonable for the users willing to accept some limitations in their special situation) solved too.
(2) The problems I presented in the blog post involve almost no human stupidity. That is, not even a paying attention expert has a reasonable way to realize he is hacked. There is nothing in the normal flow of operations to warn him. There is no social engineering. He would have to do lots of other searches in his system to realize that something is fishy. If the computer clearly says that you are running /usr/sbin/synaptic after you clicked on it on the menu and you have no other available information to think otherwise you are not stupid if he actually runs the trojan code. That’s a technical problem, the system does not do what it clearly advertises it does (the system is not yet hacked, just the current user account; for an already hacked system this discussion is irellevant).
Even for situations where social engineering is involved the system can help you notice easier possible problems (see my gksu example above or firefox phishing filter).

For all the users that don’t fall in the special category above (I guess that most) I would apply point 4 of my post. The limited account does not help them and it is a frustrating inconvenience.

Comment on Security issues with sudo by martinpitt

martinpitt — Sun, 19 Jul 2009 12:05:58 +0000

This is not at all related to sudo itself, or how it is configured. In nowaday’s desktop world, if you manage to get a trojan into the user’s account of an admin, you have practically owned the machine. You can do that by putting ~/bin/sudo, or you can install a daemon which ptrace()s all your processes repeatedly until you find one which has a sudo tty, or you can just bring up a dialog which looks like gksu and ask for some plausible reason for entering your password. Without a complete lockdown of the user session, trojan horses will always be possible.

The root problems here are:

(1) Locking down an user account to a degree which makes trojan horses impossible would reduce the usefulness of a desktop machine to practically zero these days, and nobody would accept it.

(2) There is no technical defense against human stupidity. Trojan horses are a _social_ and _educational_ problem, not a technical one!

Comment on Security issues with sudo by idaho

idaho — Sun, 19 Jul 2009 09:39:12 +0000

In Ubuntu 9.04, the AppArmor profile for Firefox is not enabled by default (e.g. see sudo apparmor_status). So the most likely vector against a desktop user would be a zero-day flaw in Firefox or maybe a malicious plugin. I don’t want root compromised because I do my internet banking in a dedicated user account.