On Mon, Sep 23, 2024 at 09:45:00PM +0200, Guillem Jover wrote: > Package: libreswan, strongswan-starter > Severity: important > Tags: security > X-Debbugs-Cc: Helmut Grohne <hel...@subdivi.de> > > > 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? > Hey Guillem, thanks for the bug report.
I'm not sure what's the reasoning for having /etc/ipsec.secrets 644, that looks a bit spurious to me. Nowadays I hope noone really use PSK in production so I don't think there's a lot of private keys in there, but still I don't really think it needs to be world readable either. But if the strongswan-starter package already finds a file I think we should respect the permissions there, and I'm not really sure how often people statoverride them, so I'm not sure I want the package to "fix" the permissions in case they're different from 700. Regards, -- Yves-Alexis Perez
