2

It seems any program ran soon enough after sudo in the same terminal can run any sudo command it pleases.

Proof: Execute sudo ls in a terminal . Then run this program (compiled of course) in the same terminal:

#include <stdlib.h>

int main() {
    system("sudo whoami");
    return 0;
}

It'll say root without asking for a password.

Isn't this a big security hole? Root and regular accounts are separated so that, apart from other things, malicious software can't run as root. Are users supposed to be careful what they execute before sudo times out?

user438846
  • 61
  • 2
    @muru and close voters: I would say "related", not "duplicate", as it's not asking about the credential caching, it's asking whether that is an insecure in its current default, and explains the actual problem they're observing, as well as puts in the place that convenience vs. security, and that experienced sysadmins will harden their systems correctly. – Thomas Ward Jan 20 '16 at 15:26
  • 2
    I concur with Thomas, this doesn't seem like a duplicate – Sergiy Kolodyazhnyy Jan 20 '16 at 15:33
  • 1
    @ThomasW. seems to be reading a bit too much into it. I have no idea where this bit came from: "[it] puts in the place that convenience vs. security, and that experienced sysadmins will harden their systems correctly". All I see is two users surprised by credential caching, with varying reactions. – muru Jan 20 '16 at 15:37
  • 1
    @ThomasW. Though that would be primarily opinion-based, the security of the terminal one leaves accessible once having run sudo depends on the user and it's not really quantifiable, not without way more details and without ending up digressing on off-topic subjects. – kos Jan 20 '16 at 15:38
  • @kos However, consider the question here - it asks if 'sudo' is extremely insecure - this only can be answered within the defaults of the setup, because the user doesn't know/understand the backend configurations by default. The balance between security and usability is likely why the default was decideded this way - we're going to have to keep in mind that. Having said this, this shouldn't be closed as a duplicate, but it should be closed as broad, potentially, now that I look at it again. – Thomas Ward Jan 20 '16 at 15:39
  • @ThomasW. Personally I would have voted primarily opinion-based, however I (and I think mostly anyone else could do the same) clearly perceive a sense of insatisfaction / insecurity from the the user, so I think that closing as a duplicate would have the best outcome in this case, as it provides a way to cater for the "real" issue. Mostly I don't think this can be debated without digressing on subjects that really are out of the scope of the site, or even on personal opinions. – kos Jan 20 '16 at 15:56

3 Answers3

4

sudo settings by default have 15 minutes time out before reprompting for password, however one can change it to always ask for password every time you call something with sudo. The exact option is timestamp_timeout

timestamp_timeout

                   Number of minutes that can elapse before sudo will ask
                   for a passwd again.  The timeout may include a frac‐
                   tional component if minute granularity is insufficient,
                   for example 2.5.  The default is 15.  Set this to 0 to
                   always prompt for a password.  If set to a value less
                   than 0 the user's time stamp will never expire.  This
                   can be used to allow users to create or delete their
                   own time stamps via “sudo -v” and “sudo -k” respec‐
                   tively.

And here is the relevant part of my sudoers file as well as two attempts at sudo,as you can see it reprompts:

$ sudo cat /etc/sudoers                                                        
[sudo] password for xieerqi: 
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults    timestamp_timeout=0
Defaults    passwd_timeout=0
(the rest cut out)
================
xieerqi:
$ sudo echo hello
[sudo] password for xieerqi:

As another alternative, you can also use pkexec , which to my knowledge always asks for password

Sergiy Kolodyazhnyy
  • 105,154
  • 20
  • 279
  • 497
3

sudo by default in a standard Ubuntu installation keeps the sudo access cached for a short time (default is a 15-minute timeout).

For your hypothetical situation to work, you need to have run sudo earlier, and then run the code you specified with sudo before the caching of that ability times out. In most cases, this is not as 'insecure' as you think - many hardened servers have a far shorter timeout, or in my case on my servers I actually configure it for an instant timeout after sudo is executed, requiring the password for each sudo command made.

To this end, sudo is 'secure' because there's timeouts which expire, to make sure sudo can't be used infinitely and perpetually after one use.

It is not 'insecure' in this manner, though there are times where it appears that way - disabling the credential caching solves this, of course, and is very easy for system administrators to do.

In a default install, the default 15 minute caching would appear as the balance between 'security' and 'convenience', because we don't want new users to be having headaches by entering passwords for every time. Having said this, where security is important we can lock down sudo by changing the configuration.

TL;DR: No, sudo is not insecure at all. It's the default caching, and your hypothetical being called while sudo access is cached, that triggers your thought, but sudo is NOT actually insecure when configured with a short timeout, or with instant timeout, and that's done at the system administrator's decisions on those systems whether to change the default.

Rinzwind
  • 299,756
Thomas Ward
  • 74,764
  • And, of course, when it comes to convenience vs security, the average user will pick convenience over security every single time. Better to compromise a bit. – muru Jan 20 '16 at 15:25
  • @muru as i just added :) – Thomas Ward Jan 20 '16 at 15:26
  • I agree that with instant timeout it isn't insecure. I knew about the timeout but didn't expect what I described to work. – user438846 Jan 20 '16 at 15:40
  • @user438846 Escalation privileges are cached per-user, so if 'sudo' was run and then in the same session the user executed the code you provided, then it would inherit that 'allowed to escalate' privilege. To that end, it's the timing of execution and the configuration in place at fault, or rather the defaults, which don't necessarily equate to sudo being insecure. – Thomas Ward Jan 20 '16 at 15:41
  • 1
    @ThomasW. no doubts here. It is 15 minutes ;-) – Rinzwind Jan 20 '16 at 15:54
  • 2
    @user438846 Think about it. If I'm going to run a command which is going to run arbitrary commands, my biggest worry would be it running rm -rf ~, not whether it messes around with sudo. – muru Jan 20 '16 at 15:55
1

Isn't this a big security hole?

No. But yes, it is lowering security a bit in favour for convenience. You can secure a system with a 128-bit password, throw it away and nobody is ever going to get access to the system ... Secure? Yes. Convenient? Hardly ;-)

  • Leaving a system unattended where sudo is active is.
  • There is a solution to this: sudo -k cancels the current time-out. I execute this every time I leave my system and I believe the 15 minutes are active.

Are users supposed to be careful what they execute before sudo times out?

Yes and no. An admin is supposed to be careful anytime they use "sudo". Not just when it is within the 15 minute time frame. So the 2nd part of your question is not important ;)

You are an admin. You are responsible to keep your system safe.

Rinzwind
  • 299,756