Bug 1020147 - default requiretty is problematic and breaks valid usage
default requiretty is problematic and breaks valid usage
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: sudo (Show other bugs)
20
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Daniel Kopeček
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1196451 1350922
  Show dependency treegraph
 
Reported: 2013-10-17 03:12 EDT by Roman Kagan
Modified: 2017-07-27 02:28 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1196451 1233205 1350922 (view as bug list)
Environment:
Last Closed: 2014-07-15 16:08:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Example of trivially bypassing requiretty (1.34 KB, text/plain)
2017-07-26 19:28 EDT, Charles Strahan
no flags Details

  None (edit)
Description Roman Kagan 2013-10-17 03:12:38 EDT
Description of problem:

/etc/sudoers shipped with sudo modifies the default behavior to always require a controlling terminal:

...
#
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear. 
#         You have to run "ssh -t hostname sudo <cmd>".
#
Defaults    requiretty
...

However this is totally bogus because sudo will *not* ask for password if it can't set the terminal into noecho mode (unless visiblepw option is set), promptly refusing with "no tty present and no askpass program specified" message.

This breaks NOPASSWD usage, especially when sudo is run with -n switch instructing it not to ask for password at all.

Version-Release number of selected component (if applicable):
sudo-1.8.6p7-1.fc19.x86_64
but according to bug 228534 it's there since long

How reproducible:
100%

Steps to Reproduce:
1. set up NOPASSWD sudo entry
2. ssh host sudo -n command

Actual results:
execution refused with "sorry, you must have a tty to run sudo" message

Expected results:
command executed

Additional info:
Comment 1 Kashyap Chamarthy 2014-02-24 07:29:04 EST
Ping.

I was notified that this bug is one of the blockers for having Fedora as part of upstream OpenStack CI infrastructure to run Gating tests.

Daniel, when you have some time, can you please assess the nature of the problem and post your analysis for having this fixed?

Thanks.
Comment 2 Vaidas Jablonskis 2014-02-24 08:20:36 EST
This works though: ssh -t host 'sudo -n command'

I think `requiretty` is a sensible default and should not be turned off. It can be disabled per user or even per command if needed.
Comment 3 Roman Kagan 2014-02-24 08:30:45 EST
(In reply to Vaidas Jablonskis from comment #2)
> This works though: ssh -t host 'sudo -n command'

Provided the caller has a tty.  Which is not the case when running this e.g. from under a daemon.

And it makes zero sense to create a pty pair only to make (RH version of) sudo happy, without the need to pass any data through it.

> I think `requiretty` is a sensible default and should not be turned off.

Mind explaining why?  It adds no security, it diverges from the upstream, it breaks valid usage.  Is there anything on the upside?
Comment 4 Daniel Kopeček 2014-02-24 08:55:21 EST
(In reply to Roman Kagan from comment #0)
> Description of problem:
> 
> /etc/sudoers shipped with sudo modifies the default behavior to always
> require a controlling terminal:
> 
> ...
> #
> # Disable "ssh hostname sudo <cmd>", because it will show the password in
> clear. 
> #         You have to run "ssh -t hostname sudo <cmd>".
> #
> Defaults    requiretty
> ...
> 
> However this is totally bogus because sudo will *not* ask for password if it
> can't set the terminal into noecho mode (unless visiblepw option is set),
> promptly refusing with "no tty present and no askpass program specified"
> message.
> 
> This breaks NOPASSWD usage, especially when sudo is run with -n switch
> instructing it not to ask for password at all.

I agree that this might be annoying for the NOPASSWD case, but you can always use ssh -t, add custom per-command or per-user modifications (like !requiretty for a set of commands, users, etc.) to this behaviour to the sudoers.d directory. Or just simply comment out this setting if your setup needs it.
Comment 5 Roman Kagan 2014-02-24 09:24:32 EST
Well, I know how to work around this.

But nobody has yet explained why I have to.

The problem is not that it's annoying, the problem is that it's annoying for no value.  The case that it was supposed to handle is handled just fine without it.

So let me re-state the cons of this:

1) it adds no security
2) it breaks valid usage
3) it diverges from the upstream

I see no pros.  Do you?
Comment 6 Matthew Miller 2014-02-24 12:14:04 EST
Particularly since we're deviating from the upstream default, I think the pro list ought to be pretty strong, but I'm not seeing it either. As noted in the first comment, that *stated* reason is not accurate.
Comment 7 Daniel Kopeček 2014-02-25 05:42:03 EST
Ok, after re-reading the docs, it looks like i don't have any pros to write :] I'll remove the requiretty defaults and add a comment about the visiblepw option.
Comment 8 Matthew Miller 2014-02-25 08:08:49 EST
(In reply to Daniel Kopeček from comment #7)
> Ok, after re-reading the docs, it looks like i don't have any pros to write
> :] I'll remove the requiretty defaults and add a comment about the visiblepw
> option.

Awesome -- thanks!
Comment 9 Matthew Miller 2014-07-15 16:08:01 EDT
I'm going to close this bug, as it was fixed in march:

* Mon Mar 10 2014 Daniel Kopecek <dkopecek@redhat.com> - 1.8.8-3
- remove bundled copy of zlib before compilation
- drop the requiretty Defaults setting from sudoers
Comment 10 Wade Mealing 2017-04-03 00:34:55 EDT
> It adds no security

This is incorrect.  This -definitely- makes it harder for a local application without a tty to abuse sudoers if there is a 'shell like' environment that attackers may use.
Comment 11 Charles Strahan 2017-07-26 19:28 EDT
Created attachment 1305084 [details]
Example of trivially bypassing requiretty

This provides a recipe for circumventing requiretty for the sake of running rsync on a target machine as root. All that's needed on the target machine is `bash`, `script` and `rsync`.
Comment 12 Charles Strahan 2017-07-26 19:37:43 EDT
>> It adds no security

> This is incorrect.  This -definitely- makes it harder for a local application without a tty to abuse sudoers if there is a 'shell like' environment that attackers may use.

Wade, is there some angle I'm missing? Per my last attachment, it seems like requiretty is pretty trivial to side step, even for slightly nuanced scenarios (which, I think, the rsync case qualifies).

Note You need to log in before you can comment on or make changes to this bug.