permission denied when executing dhclient in Ec2 datasource

Bug #1717627 reported by Scott Moser on 2017-09-16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Chad Smith
cloud-init (Ubuntu)
Ubuntu Security Team

Bug Description

in the ec2 datasource, cloud-init runs dhclient from a tmp file in order to avoid apparmor restrictions and side affects.

In a change for bug 1707222 we started using /run/cloud-init for tmpfiles.
/run is mounted noexec. See example:

$ sudo /run/cloud-init/tmp/dhclient -1 -v -lf /run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/dhcp.leases -pf /run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/ eth0 -sf /bin/true
sudo: unable to execute /run/cloud-init/tmp/dhclient: Permission denied

So, we need a tmp file in a place that allows execution.

Related bugs:
 * bug 1709772: Enable ipv6 support on EC2
 * bug 1707222: usage of /tmp during boot is not safe may get files deleted.
 * bug 1717627: permission denied executing dhclient from /run

Related branches

Scott Moser (smoser) on 2017-09-16
Changed in cloud-init:
status: New → Confirmed
importance: Undecided → High
Changed in cloud-init (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Chad Smith (chad.smith) on 2017-09-16
Changed in cloud-init:
assignee: nobody → Chad Smith (chad.smith)
status: Confirmed → In Progress
milestone: none → 0.7.10
Dimitri John Ledkov (xnox) wrote :

I would hope that
$ sudo /sbin/dhclient -1 -v -lf /run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/dhcp.leases -pf /run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/ eth0 -sf /bin/true

Should work fine.

And if /run/cloud-init/tmp/dhclient is not just a copy of /sbin/dhclient, then it should be shipped in the package as /usr/lib/cloud-init/dhclient or some-such. With an apparmor profile applied to it.

dhclient is something that could be remotely exploited, thus protecting it - even if for cloud-init Ec2Local initialisation would be nice.

Can you attach the contents of /run/cloud-init/tmp/dhclient ? Can you elaborate on "in order to avoid apparmor restrictions and side affects"? Is this in fact a bug in Ubuntu stock apparmor profiles?

information type: Public → Public Security
Changed in cloud-init (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Scott Moser (smoser) wrote :

Cloud-init has two stages that probe/discover a datasource (cloud-platform)
and obtain information on that. They are 'local' and 'network'. The local
phase is guaranteed to run before system networking comes up and can read
networking configuration from the datasource.

For further documentation see

Some cloud platforms provide network configuration information on a network
resource. Thus, in order to get this network information, cloud-init has
to configure some networking (ipv4 link local on DigitalOcean, dhcp on
EC2) to get information. When it does this, it tears down the ephemeral
networking that it set up, writes the system configuration and lets the
system bring up the persistent/complete network info.

EC2's network based metadata service (available on
provides network information. In order to get a response from the meta-data
service, the source address of request must be the address that is returned
in a dhcpv4 request. The requirement is then to to do a dhcp request on
a given network device.

Rather than writing our own dhcp client, we chose to do this by utilizing
dhclient and executing it in a way that it did not invoke hooks or otherwise
have side affects on the system. In order to do that, we invoke like
   dhclient -1 -v -lf /tmp/my.leases -sf /bin/true
That is to control where the lease_file is written and to not execute any

Our invocation of dhclient causes issues with the default Ubuntu shipped
dhclient apparmor profile as it does not allow execution of /bin/true.
The solution we employed was to skip app armor constraint by copying
/sbin/dhclient to a temporary file and execute it there. Other options
were to
 * disable apparmor temporarily (which would leave scary warning messages
   in the log).
 * ship a wrapper around dhclient and a apparmor profile.

Our most recent issue with the solution we used is bug 1717627. That
was a result of using /run/cloud-init which is mounted noexec rather than
/tmp/ (to fix bug 1707222).

Lastly, the change from using dhclient to using systemd-networkd's dhcp client
will cause a fair amount of fallout across Ubuntu. That will cause problems
with cloud-init on Azure. Many things either relied on dhclient hooks
or read its leases file. I've opened bug 1717983 to track that.

Summary of generally involved bugs:
 * bug 1709772: Enable ipv6 support on EC2
 * bug 1707222: usage of /tmp during boot is not safe may get files deleted.
 * bug 1717627: permission denied executing dhclient from /run
 * bug 1717983: cloud-init and other programs integrate with dhclient.

description: updated
Chad Smith (chad.smith) on 2017-09-19
Changed in cloud-init:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cloud-init - 0.7.9-283-g7eb3460b-0ubuntu1

cloud-init (0.7.9-283-g7eb3460b-0ubuntu1) artful; urgency=medium

  * New upstream snapshot.
    - ec2: Fix maybe_perform_dhcp_discovery to use /var/tmp as a tmpdir
      [Chad Smith] (LP: #1717627)
    - Azure: wait longer for SSH pub keys to arrive.
      [Paul Meyer] (LP: #1717611)

 -- Scott Moser <email address hidden> Mon, 18 Sep 2017 20:41:53 -0400

Changed in cloud-init (Ubuntu):
status: Confirmed → Fix Released

This bug is believed to be fixed in cloud-init in 17.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in cloud-init:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers