Tagged devices should not have access permissions of their owning user

[vbrandl]

Bug description

I want to allow my personal devices to ssh into my servers but not allow my servers to ssh between each other. All devices belong to the same headscale user. My servers are tagged ssh, my personal devices are untagged and my user is in the sshuser group.

The Tailscale documentation states (https://tailscale.com/kb/1068/acl-tags/#authentication-and-authorization):

Once a device has been tagged, it loses the access permissions of the human user who tagged it, and acquires any access permissions granted to its tags. In other words, if you log into a device as [email protected] and then tag it with tag:server, the device no longer has any of the network permissions granted to [email protected], and instead is subject to the access rules for tag:server. If the user who added the device is deleted, the device will remain.

According to the Tailscale documentation, I would expect a ACL allowing ssh from group:sshuser to tag:ssh to produce the described behaviour. All my untagged devices should be able to ssh into the tagged servers (which they do) but my servers are also able to ssh between each other.

To Reproduce

{
    "groups":{
        "group:sshuser":[
            "me"
        ]
    },
    "tagOwners": {
        "tag:ssh": ["me"]
    },
    "ssh": [
        {
            "action": "accept",
            "src": ["group:sshuser"],
            "dst": ["tag:ssh"],
            "users": ["allowlisted-user"]
        }
    ]
}

Context info

• Headscale: v0.22.1

[github-actions[bot]]

This issue is stale because it has been open for 180 days with no activity.

[vbrandl]

This seems like a security bug to me, since it does not match the behavior of tailscale. Can anyone with more in-depth knowledge comment on this?

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity.

[kradalby]

Yes, you are right, they should be "detached" from the user when they are tagged. Right now we dont have the code necessary to handle this. I have removed the stale tag for further tracking.

Per now I would classify it as "ACLs are not fully implemented" rather than a security bug as we do not support all features.

[vbrandl]

Since there are various places in the headscale documentation, that link to https://tailscale.com/kb/1068/acl-tags, where the "detaching" behavior is described, I would still consider this a security bug. As a user reading the documentation, it is not clear, where and how headscale diverges from tailscale. This seems dangerous to me...

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity.

[vbrandl]

I don't think this should be marked as stale and forgotten...

[kradalby]

I agree, removed the mark, we just have not had capacity to get to it.

[kradalby]

I made a PR doing some of the untangeling work to make this possible, removing the username from magicdns names. Which should make this a tiny bit easier.

[mikelococo]

... removing the username from magicdns names.

Are there any suggested strategies for maintaining hostname continuity in the face of this change? This seems like a more-significant-than-usual breaking change in that it's likely to require changes not just to the headscale config but to potentially all services and clients on the tailnet that know each other by their MagicDNS name.

I see in https://github.com/juanfont/headscale/releases/tag/v0.23.0-beta1 that it suggests a temporary workaround, but one that is planned to be removed:

use_username_in_magic_dns can be used to turn this behaviour on again, but note that this option will be removed when tags are fixed.

Does extra_records provide a path to maintain the existing MagicDNS entries? https://github.com/juanfont/headscale/blob/main/docs/dns-records.md discusses the config-format but is silent on the relationship between extra_records, base_domain, and auto-assigned MagicDNS entries. Is using extra_records to emulate the old username-style subdomains valid?

If one only cares about dns name continuity for the nodes registered to a single user, is modifying the base_domain of an existing tailscale instance a valid migration strategy? For example, chaging the base_domain from example.com to myuser.example.com such that all nodes now appear at the FQDN previously reserved for nodes registered to myuser.

I feel like this change in particular is likely to generate migration/support questions due to the very disruptive nature of changing existing names, some amount of migration guidance would be quite helpful as the release nears.