CNAME record leaks into juju's private-address, breaks host based access control

Bug #1250435 reported by Andreas Hasenack on 2013-11-12
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
MAAS
High
Raphaël Badin
maas (Ubuntu)
Undecided
Unassigned

Bug Description

Mailing list thread, for reference: https://lists.launchpad.net/maas-devel/msg01375.html

Some charms use the relation value "private-address" to set host based access controls. Postgresql, for example, uses this value for the pg_hba.conf line like this:

host all all kmkxr.maaslocal md5

In the case of MAAS, that value is the CNAME record for that host:
# host kmkxr.maaslocal
kmkxr.maaslocal is an alias for 10-0-5-100.maaslocal.
10-0-5-100.maaslocal has address 10.0.5.100

And this breaks the access control:
2013-11-07 13:47:02 UTC FATAL: no pg_hba.conf entry for host "10.0.5.100",
user "landscape", database "landscape-standalone-main", SSL off
2013-11-07 13:47:02 UTC DETAIL: Client IP address resolved to
"10-0-5-100.maaslocal", forward lookup not checked.

It's also how openssh behaves. If you setup a key in authorized_hosts to only accept connections from a specific hostname, this is what happens:

Nov 11 11:45:49 wfaxq sshd[2332]: Authentication tried for ubuntu with correct key but not from a permitted host (host=10-0-5-103.maaslocal, ip=10.0.5.103).
Nov 11 11:45:49 wfaxq sshd[2332]: Connection closed by 10.0.5.103 [preauth]

/home/ubuntu/.ssh/authorized_keys:
from="k8q9m.maaslocal" ssh-rsa AAAAB3NzaC1yc2EA...

# host k8q9m.maaslocal
k8q9m.maaslocal is an alias for 10-0-5-103.maaslocal.
10-0-5-103.maaslocal has address 10.0.5.103

As long as the CNAME record is what shows up in juju's private-address, these types of access controls won't work. It doesn't happen with the AWS, LXC and OpenStack providers (didn't test others).

Some options were briefly discussed:
a) Drop the CNAME entirely and keep the generated A and PTR records only
b) Keep the CNAME, but use the A record for the private-address (and probably the actual $(hostname -f) of the unit)
c) Drop the CNAME and use the "friendly" name for the A record

Possibly others I forgot.

Related branches

Changed in maas:
status: New → Triaged
importance: Undecided → High
milestone: none → 14.04
tags: added: dns papercut
tags: added: landscape
Julian Edwards (julian-edwards) wrote :

Escalated by Dean.

Changed in maas:
importance: High → Critical
Andres Rodriguez (andreserl) wrote :

Andreas and I found out that the use of socket.gethostbyname should be enough to fix this in the charm.

Andreas Hasenack (ahasenack) wrote :

I filed bug #1276807 to use socket.gethostbyname() in the postgresl charm.

On Wednesday 05 Feb 2014 17:16:22 you wrote:
> Andreas and I found out that the use of socket.gethostbyname should be
> enough to fix this in the charm.

OK. We're going to change maas anyway, as this will trip people up.

James Troup (elmo) on 2014-03-05
tags: added: canonical-is
Changed in maas:
importance: Critical → High
Changed in maas:
milestone: 14.04 → 14.10
Changed in maas:
assignee: nobody → Raphaël Badin (rvb)
status: Triaged → In Progress
Raphaël Badin (rvb) wrote :

We've dropped the CNAME records. The private-address is now an A record.

Forward zone:
hostname → (A) → IP

Reverse zone:
IP → (PTR) → hostname

Changed in maas:
status: In Progress → Fix Committed
Yaguang Tang (heut2008) wrote :

Is it possiable to backport this fix to current MaaS 1.5.2 in trusty ? This is required for rabbitmq-server charm to works well in active/active clusteing mode.

Julian Edwards (julian-edwards) wrote :

On Wednesday 23 Jul 2014 07:25:34 you wrote:
> Is it possiable to backport this fix to current MaaS 1.5.2 in trusty ?
> This is required for rabbitmq-server charm to works well in
> active/active clusteing mode.

That's not going to happen because 1.6 is being released soon, which should
get uploaded to trusty.

Robie Basak (racb) on 2014-07-29
Changed in maas (Ubuntu):
status: New → Triaged
Changed in maas:
status: Fix Committed → Fix Released
Edward Hope-Morley (hopem) wrote :

@julien-edwards no sign of 1.6 or this patch in trusty yet. Is it still planned for 1.6 to be released for trusty? If not can this patch be backported to trusty?

Julian Edwards (julian-edwards) wrote :

1.6 is not going to be uploaded to any Ubuntu release, please look out for 1.7 in Utopic. 1.7 *may* be backported to Trusty but it depends on ongoing techboard approval.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers