Skip to content

Add warning if REST API is accessible through an insecure connection#37684

Merged
tiborvass merged 1 commit intomoby:masterfrom
thaJeztah:add_remote_api_warning
Aug 21, 2018
Merged

Add warning if REST API is accessible through an insecure connection#37684
tiborvass merged 1 commit intomoby:masterfrom
thaJeztah:add_remote_api_warning

Conversation

@thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Aug 21, 2018

The remote API allows full privilege escalation and is equivalent to having root access on the host. Because of this, the API should never be accessible through an insecure connection (TCP without TLS, or TCP without TLS verification).

Although a warning is already logged on startup if the daemon uses an insecure configuration, this warning is not very visible (unless someone decides to read the logs).

This patch attempts to make insecure configuration more visible by sending back warnings through the API (which will be printed when using docker info).

- Description for the changelog

+ Add warning if REST API is accessible through an insecure connection [moby#37684](https://github.com/moby/moby/pull/37684)

- A picture of a cute animal (not mandatory but encouraged)

cute-ugly-wombat1

@thaJeztah thaJeztah requested a review from vdemeester as a code owner August 21, 2018 13:54
@thaJeztah thaJeztah added status/2-code-review kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. area/security and removed status/0-triage labels Aug 21, 2018
@thaJeztah
Copy link
Member Author

ping @vdemeester @cpuguy83 @justincormack

related to #37299 (/cc @cyphar)

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🐸

Copy link
Member

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems ok, but I don't like that it's parsing hosts for the info endpoint, especially since these don't change while the daemon is running.

Since we already have to parse the hosts can we store this info somewhere?

daemon/info.go Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, this should be a constant.

@thaJeztah
Copy link
Member Author

Actually; may not even need the ParseHost(), because the startup code parses this, and writes it back to Config;

moby/cmd/dockerd/daemon.go

Lines 593 to 595 in cf72051

if cli.Config.Hosts[i], err = dopts.ParseHost(cli.Config.TLS, cli.Config.Hosts[i]); err != nil {
return nil, fmt.Errorf("error parsing -H %s : %v", cli.Config.Hosts[i], err)
}

@thaJeztah thaJeztah force-pushed the add_remote_api_warning branch from 8d25be5 to ab05c66 Compare August 21, 2018 18:07
@codecov
Copy link

codecov bot commented Aug 21, 2018

Codecov Report

❗ No coverage uploaded for pull request base (master@2629fe9). Click here to learn what that means.
The diff coverage is 0%.

@@            Coverage Diff            @@
##             master   #37684   +/-   ##
=========================================
  Coverage          ?   36.01%           
=========================================
  Files             ?      609           
  Lines             ?    45060           
  Branches          ?        0           
=========================================
  Hits              ?    16229           
  Misses            ?    26605           
  Partials          ?     2226

@thaJeztah
Copy link
Member Author

@cpuguy83 updated; PTAL

@thaJeztah thaJeztah force-pushed the add_remote_api_warning branch from ab05c66 to 34441c2 Compare August 21, 2018 18:10
daemon/info.go Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/without TLS protection/unencrypted/

daemon/info.go Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TLS client verification

@cyphar
Copy link
Contributor

cyphar commented Aug 21, 2018

LGTM, after @cpuguy83's comments are addressed.

daemon/info.go Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably fine for this PR, but it would be nice to eliminate this by being able to do something like host.Protocol()

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes; tried to keep this PR minimal, but I'm thinking of exposing some of this information (e.g., the configured hosts) in docker info as well. I can do some refactoring as part of that 👍

The remote API allows full privilege escalation and is equivalent to
having root access on the host. Because of this, the API should never
be accessible through an insecure connection (TCP without TLS, or TCP
without TLS  verification).

Although a warning is already logged on startup if the daemon uses an
insecure configuration, this warning is not very visible (unless someone
decides to read the logs).

This patch attempts to make insecure configuration more visible by sending
back warnings through the API (which will be printed when using `docker info`).

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah force-pushed the add_remote_api_warning branch from 34441c2 to 547b993 Compare August 21, 2018 20:03
@thaJeztah
Copy link
Member Author

Thanks for reviewing @cyphar 🤗

Copy link
Member

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@andrewhsu
Copy link
Contributor

Please ignore powerpc build results. The IBM Power infrastructure is experiencing outage at the moment.

Copy link
Contributor

@tiborvass tiborvass left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/security kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. status/4-merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants