#1188 Request for a soft-static GID allocation for group "ssh_keys" (package "openssh")
Closed: accepted 2 years ago by lucab. Opened 2 years ago by lucab.

Following the instructions at https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_soft_static_allocation, this ticket is to request the allocation of a static group ID (GID) for the group "ssh_keys" belonging to package "openssh".

The rationale behind this static GID request is that the openssh package is currently shipping a binary at /usr/libexec/openssh/ssh-keysign which has the set-group-id bit set and ownership of root:ssh_keys:

$ stat /usr/libexec/openssh/ssh-keysign
  File: /usr/libexec/openssh/ssh-keysign
  Size: 334248          Blocks: 656        IO Block: 4096   regular file
Access: (2555/-r-xr-sr-x)  Uid: (    0/    root)   Gid: (  999/ssh_keys)

Moving this group to a static GID will:
* improve OS content reproducibility (by having stable UID/GID in file metadata)
* avoid possible security mixups (due to setGID execution and dynamic GID)
* improve deterministic consistency for systems performing out-of-band composes (e.g. ostree and other image-based technologies)

For cross-reference, see details at https://bugzilla.redhat.com/show_bug.cgi?id=2104595.


/cc @tibbs @james

I'm not sure I'll be around in your meeting if you want to discuss this there, but I can preemptively add details here if needed.

Also, while I don't personally see any issue with this approach, it would be good to get some feedback from the assignee/maintainer @dbelyavs.

As for the actual GID allocation, the lowest free number at this time seems be 101.

Thus I'm proposing to reserve GID 101 for group ssh_keys as used by package openssh.

Sorry for the delay with response. I don't see any caveats.

@dbelyavs thanks for the feedback and no worries. I'm happy to do the groundwork for this, I just didn't want to overstep your opinion.

I saw this was covered in the meeting on 2022-07-14 and there was no obvious blocker.

I think this is only missing an official ACK from the FPC, and the confirmation of the proposed 101 GID.

@decathorpe @james @tibbs can somebody please confirm that? Then I'll go ahead with PRs to the uidgid table and to the openssh specfile.

+1

We didn't have enough members present to call a formal vote during the meeting, and there's not many votes in this ticket either, but I don't think we should make you wait because of that. So unless somebody screams "STOP!" within the next hours, I think you're good to go.

Is ssh-keysign used on Fedora by default? The man page says:

 ssh-keysign is disabled by default and can only be enabled in the global
 client configuration file /etc/ssh/ssh_config by setting EnableSSHKeysign
 to “yes”.

Like I don't think the three points are an auto accept for any package (unless we want to decide that everything we ship in ostree images should get them) ... but if it's used by default in ssh (so basically everywhere) then it's an easy +1.

everything we ship in ostree images should get them

While I'm personally coming from a CoreOS / ostree background, I'm trying to avoid framing this as an ostree-specific thing. In fact, this affects any kind of system which tries to perform reproducible / out-of-band composes and then try to share/deploy the resulting OS content.
While ostree is the most common case nowadays, the field is broader than that and the packaging guidelines already acknowledge this in a more generic way (Explain how the uids and gids are being shared between computers).
When we are done with this first round of fixes for CoreOS, we'd like to expand this to a Fedora-wide "FS metadata/IDs determinism" push, see https://github.com/coreos/fedora-coreos-config/issues/1826#issuecomment-1184377269.

Is ssh-keysign used on Fedora by default?

To my knowledge, everywhere the sshd.service is started, the key-generation logic (performed by sshd-keygen@.service) is enabled by default through the sshd-keygen.target target.

@james did my previous reply answer your concerns? It's look like all the other replies were already positive, thus let me know if you are ok with this as well or if there are details that you want to touch on.

everything we ship in ostree images should get them

While I'm personally coming from a CoreOS / ostree background, I'm trying to avoid framing this as an ostree-specific thing. In fact, this affects any kind of system which tries to perform reproducible / out-of-band composes and then try to share/deploy the resulting OS content.
While ostree is the most common case nowadays, the field is broader than that and the packaging guidelines already acknowledge this in a more generic way (Explain how the uids and gids are being shared between computers).

To be clear I understand this, but 1) ostree is what is generating these kinds of images now (and for some years), so as a shorthand it's simpler to refer to it as ostree. 2) I'd lean towards just +1 soft *ids for anything in the default ostree images (on my assumption that it's going to be 10-100 things).

Is ssh-keysign used on Fedora by default?

To my knowledge, everywhere the sshd.service is started, the key-generation logic (performed by sshd-keygen@.service) is enabled by default through the sshd-keygen.target target.

ssh-keygen is not ssh-keysign, right?
The former is owned by root/root, and AFAICS the later isn't used by any ssh service files:

% fgrep keysign /usr/lib/systemd/system/sshd*

...again the man page says it's activated by a config option, and AFAICS that option isn't on by default.

Also FWIW we are now at +4 ... so if anyone who hasn't voted wants to +1, comment that and close the ticket as accepted.

Thanks all, I did update the uidgid allocation table and fixed the openssh package to use the newly reserved GID:
* https://pagure.io/setup/pull-request/41
* https://src.fedoraproject.org/rpms/openssh/pull-request/32

Metadata Update from @lucab:
- Issue close_status updated to: accepted
- Issue status updated to: Closed (was: Open)

2 years ago

Sorry for a delay, but I just wanted to clarify some assumptions mentioned in the previous comments. The ssh_keys group is used for two things: The generated keys in /etc/ssh/ are assigned this group, which should be to no concern as the /etc should never be shared. The problematic use is the group on the executable in /usr/libexec/openssh/ssh-keysign, which can be shared and result in different group id even though the group name is supposed to be the same.

The ssh-keysign is used only during the hostbased authentication in SSH protocol, which is not enabled by default, but is common in cluster deployments where this simplify trust handling between different servers by allowing normal users to use the normally-accessible-only-by-root ssh host keys for authentication. This is done with the setGID bit on the binary.

The ssh-keygen does not have anything to do with this use case.

Given the above, I agree that the static GID is a step in the right direction.

Login to comment on this ticket.

Metadata