The _apt user ignores group membership.

[Reik Keutterling]

Actually I had the same problem described in http://askubuntu.com/questions/773955/apt-get-ssl-client-certificate-not-working-on-16-04-error-while-reading-file
I want to use client certificates with apt. But I don't want to make them world readable in order to make apt working. So I created a group 'ssl-cert' and changed the group ownership of the ssl cert files to match this group. I also added the _apt user to the ssl-cert group.

Then I tried to open these files as user '_apt' in bash (su -s /bin/bash _apt) which works well.

But if I run: "apt-get -o "Debug::Acquire::https=true" update" I still get the following error:
* error reading ca cert file /etc/certs/mycert/ca.pem (Error while reading file.)
* Closing connection 26

So my guess is that apt somehow ignores the ssl-cert membership.

Possible workarounds:
- make ssl client cert world readable
- change owner ssl client cert to _apt
- change main group of _apt user from 'nogroup' to 'ssl-cert'
- set APT::Sandbox::User "root"; in apt.conf.d

Neither of them is pretty.
Maybe this is a wanted behavior, then just suggest how to fix the issue in nice way.

[David Kalnischkies (donkult)]

The recommended way is "chown _apt:root FILE && chmod 400 FILE" at the moment. Ideally we wouldn't need the chown (or have it root:root), but that isn't very realistic to be implementable without rolling our own TLS stack in the process at the moment, so we have to make due with that for now.
Disabling the feature or making the file world readable does work as well, but totally defeats the point of course…

I don't see what the point of trying to us groups here is. Are you trying to share the same certificate for multiple things? If so that's a bad idea. You should have a certificate for each and every usecase (= client), not a single one shared between multiple clients on the same machine.

[Reik Keutterling (r-keutterling)]

Ok, but:

Why is it a bad idea to have a shared client certificate between multiple client applications on the same host?
Why is apt-get just not "respecting" the groups of the _apt user?

[Graham Leggett (minfrin)]

Dictating to people what their PKI policy should be is outside the scope of apt. Apt must behave properly as per standard unix behaviour, with a proper working user and a proper working group. Trying to dictate directory permissions to people breaks automation, breaks orchestration, and makes it really hard to convince people to do security properly.

Please fix this.

[Julian Andres Klode (juliank)]

Dropping all secondary groups is standard security practice for sandboxing.

[David Kalnischkies (donkult)]

Nowadays our HTTPS implementation works a few layers deeper than what I talked about three years ago, so we could similar to our auth.conf work now open all certificate (others also?) files as root before dropping rights. As that would be best implemented by someone who actually uses these features in practice for easier testing: Any takers?

[Michael (wattersm)]

Has any progress been made on this issue?

[Julian Andres Klode (juliank)]

Subscribing ubuntu-security as I'd like to hear some insight from the security team how switching groups would work when sandboxing, and whether that makes sense.

[Julian Andres Klode (juliank)]

You can of course use ACLs to grant permissions to _apt to individual files.

[Seth Arnold (seth-arnold)]

Changing away from 'nogroup' would be good, that's for NFS use (similar to 'nobody').

Using ACLs to grant the _apt user permission to work with specific files sounds good to me. Perhaps not all editors know to maintain those when writing new files with the same name, or perhaps know to fall back to non-atomic file update tools in order to maintain those...

But it'd be ideal from apt's perspective, and easier than trying to manage supplementary groups in sandboxed processes.

Thanks