[Pkg-utopia-maintainers] Bug#941609: Bug#941609: network-manager: generates world-{read, execut}able secret_key file (in buster)

[Michael Biebl]

Am 02.10.19 um 20:07 schrieb Thorsten Glaser:
> Package: network-manager
> Version: 1.14.6-2
> 
> src/nm-core-utils.c has:
>    2896                 } else if (!nm_utils_file_set_contents (SECRET_KEY_FILE,
>    2897                                                         (const char *) new_content,
>    2898                                                         len,
>    2899                                                         0077,
>    2900                                                         &error)) {
> 
> Fixed in 1.20.4-1 (sid):
>    2698                 } else if (!nm_utils_file_set_contents (SECRET_KEY_FILE,
>    2699                                                         (const char *) new_content,
>    2700                                                         len,
>    2701                                                         0600,
>    2702                                                         &error)) {
> 

Relevant upstream bug report

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/175

Contrary to the comments in
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/613af1de95182c69bd30e09a4139b172bf2e1a70

/var/lib/NetworkManager is 755 on Debian (as it is created via
network-manager.dirs). So bringing the security team into the loop here.

At a first glance, this does not look too critical. The secret key is
used as follows:

> * Support and use a new kind of secret-key in "/var/lib/NetworkManager/secret_key".
>   The secret-key represents the identity of the machine that is used for various
>   purposes like generating IPv6 stable privacy addresses. It is now combined
>   with "/etc/machine-id" so that changing only the machine-id results in new identifiers.
>   That matters for example when cloning a virtual machine. Previously, the user
>   hard to prune NetworkManager's secret-key to get a new identity, now regenerating
>   machine-id suffices. Secret-keys generated by earlier versions of NetworkManager are
>   not affected and keep their previous behavior.

Aside from cherry-picking the upstream commit, I guess we should fix up
the permissions of /var/lib/NetworkManager/secret_key on upgrades and
also make sure we use 700 for /var/lib/NetworkManager/ as upstream intended.

@security team: Do you think this is sufficient? Should we re-generate
the key? Should this be fixed via a stable upload or a security upload?

I'm leaning towards keeping the existing secret-key file and fixing this
via stable, but I'd welcome your feedback here.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20191003/86f75863/attachment.sig>