Package: libreswan, strongswan-starter
Severity: important
Tags: security
X-Debbugs-Cc: Helmut Grohne <hel...@subdivi.de>
Hi!
While analyzing the archive for mismatched file metadata (as part of
the preparation to add support into dpkg), thanks to Helmut gathering
the data from the archive. I noticed that these two packages (which
cannot be co-installled via libresawn Conflicts on strongswan-starter)
have a mismatch in the permissions for the /etc/ipsec.secrets file,
where there could be security implications, as this is a conffile,
that can be left around on removal (not purge), and then the
installation of the other package then inherits the previous file
permissions:
$ dpkg-deb -c libreswan_4.14-1_amd64.deb |grep etc/ipsec\.secrets
-rw-r--r-- root/root 603 2024-03-12 02:01 ./etc/ipsec.secrets
$ dpkg-deb -c strongswan-starter_5.9.13-2+b1_amd64.deb \
| grep etc/ipsec\.secret
-rw------- root/root 175 2024-03-10 06:45 ./etc/ipsec.secrets
An example problematic session:
# apt install strongswan-starter
# ls -la /etc/ipsec.secrets
-rw------- 1 root root 175 Mar 10 2024 /etc/ipsec.secrets
# apt purge strongswan-starter
# apt install libreswan
# ls -la /etc/ipsec.secrets
-rw-r--r-- 1 root root 603 Mar 12 2024 /etc/ipsec.secrets
# apt remove libreswan
# -rw-r--r-- 1 root root 603 Mar 12 2024 /etc/ipsec.secrets
# apt install strongswan-starter
# ls -la /etc/ipsec.secrets
-rw-r--r-- 1 root root 175 Mar 10 2024 /etc/ipsec.secrets
So on their own, both file permissions seem correct, given how they
are intended to be used and documented as such by their respective
packages. The problem is with the interaction between them given that
they share the same pathname *and* are conffiles.
I think either libreswan should match the permissions from
strongswan-starter (to be on the safe side anyway) and avoid this bad
interaction, or if that is not desired then strongswan-starter should
check whether the file has safe permissions (and they have not been
statoverridden) and otherwise correct them during installation. The
latter would need to be done in any case to recover from a scenario
like the above though.
I've assigned to both for awareness and coordination purposes, feel free
discuss the best course of action and reassign to whichever might need
to adapt the permissions. As this seems to me to have security
implications I've tagged it as such, depending on how good or bad this
is (perhaps strongswan refuses to operate on unsafe permissions), then
you might need to rise the severity, and perhaps prepare a change for
a stable update too?
Thanks,
Guillem
