Dear Maintainer,

A recent upload of backported libvirt packages introduced policykit-1
hard dependency on libvirt-daemon-system package.

Such dependency is unnecessary strict, as 'polkit' authentication type
(according to the /etc/libvirt/libvirtd.conf) is not the only
authentication libvirtd can use (it's trivial to modify libvirtd.conf to
remove the need of polkit), although libvirtd uses 'polkit' as the
default authentication type.

Regardless of how suitable such dependency is for jessie, please
consider downgrading policykit-1 dependency to recommends for
wheezy-backports at least.

Having polkit installed and doing nothing (for people switching to
socke based permission checks) is IMHO a better service to our users
than having all the bugs for people installing without recommends (and
there are many of those). Disabling polkit requires a bit of detailed
knowledge to not introduce security holes e.g. via the socket
activation file.

I'll leave this open to hear about other opinions but I don't see any
drawbacks on depending on polkit by default.
Cheers,
 -- Guido

I agree that libvirtd insists on using 'polkit' authentication by
default. I disagree that there's special knowledge required for
disabling 'polkit' correctly it as all that's really required is to
uncomment unix_sock_group, unix_sock_ro_perms and unix_sock_rw_perms in
libvirtd.conf (which has sane defaults for these), and to change
auth_unix_ro and auth_unix_rw to none.

And in absence of running policykit-1 libvirt simply does not allow
anyone other than root using its sockets (which is the most secure
default setting IMO).

Introducing yet another privilege escalation mechanism on unsuspecting
servers is a drawback in my book. Especially if said mechanism has
less-than-stellar security record.


At least, please update NEWS.Debian (or README.Debian) for libvirt with
explanation of libvirt's usage of policykit-1.

Reco

And what about /lib/systemd/system/libvirtd.socket ?

I'm happy to apply patches that improve the situation (either code
wise or documentation wise) but until the I'd rather not turn this
into a recommends.
Cheers,
 -- Guido

A good point. That's something I missed due to not using systemd in
wheezy.

Attaching a documentation patch for now. Should apply cleanly against
1.2.9-3~bpo70+1 Debian source. I took the liberty of reusing your name
in the NEWS file as I don't intend to disclose mine. I also transfer
an authorship of this patch and all appropriate rights to the Debian
Libvirt Maintainers.

Reco

Hi Reco,

Thanks for the path but we have this in libvirt-daemon-system.NEWS
already - and that's the package that depends on systemd. We rather
need an update to README.Debian of libvirt-daemon-system explaining
how to  _exactly_  configure socket based security.
Cheers,
 -- Guido

 Hi.

Misunderstood you. Here's the patch, but I'm lost here somewhat -
README.Debian is provided by libvirt-bin package only, which is marked
as a transitional one.
Should I rename README.Debian to libvirt-daemon-system.README?
Or should I do it old-fashioned way by appending README.Debian to
libvirt-daemon-system.examples?
I don't *that* familiar with these new dh_ tricks :(

And, a usual thing - hereby transferring an authorship of this patch
and all appropriate rights to the Debian Libvirt Maintainers.

Reco

Hi,

Guido Günther wrote:

+1

I actually decided to not use libvirt on Wheezy, because I noticed
that it would pull in policykit when I will upgrade the server to
Jessie. I do not want any freedesktop.org middleware on any of my
servers. There are usually no other users than root which will use lxc
on servers, hence there's no need for policykit.

Actually I would have written this bug report if Reco wouldn't have.

Besides pulling in stuff meant for some specific desktop environments
on servers, I see it as policy violation of a "should" directive: "The
Recommends field should list packages that would be found together
with this one in all but unusual installations."
(https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps)

Hence I would have reported it at level "important", not "minor".

Guido Günther wrote:

There are people who use other init systems.

		Regards, Axel

On Sat, Nov 15, 2014 at 11:23:58AM +0100, Axel Beckert wrote:
[..snip..]

My point exactly. To _have_ a choice we need to properly document what
to change for _all_ init systems.
 -- Guido

 Sorry to interrupt your discussion, but:

On Sun, 16 Nov 2014 10:17:55 +0100 Guido Günther <agx@sigxcpu.org> wrote:

As of current sid and experimental, libvirt-daemon-system provides a
generic init script and a systemd's unit. There's nothing
upstart-specific in the package, for example.

Therefore, there're only two cases to document - systemd one (being a
default init in jessie, this case deserves special treatment indeed),
and a generic one (i.e. anything other than systemd).

Both cases were addressed (I hope) in the patch I've sent to this bug
report earlier.

Reco

--- Please enter the report below this line. ---

Is there anything missing in the documentation patch offered by Reco on the 7th
of November 2014?
From my point of view it clearly documents access control with and without
policykit as well as the special treatment possibly necessary when using
systemd without policykit.

Just the first word of Reco's patch needs to be changed from "Remove" to
"Remote".

Or is anything else missing?

Cheers,
Lars

Hi all, hi Guido!

I just wanted to throw in my 2c. While cleaning up some machines, I
came along my KVM host and actually wondered why policykit was pulled
in.  I'm as well only using root-based access to libvirt, which keeps
all the systemd stack installed.

  I admit that I'm not too deep into the details of packaging. It's
probably a good thing to pull polkit in the first place, since it's
probably used. However, I'd be quite happy to see a way getting rid of
the (hard) dependency, allowing to deinstall polkit and its
dependencies.  Going a route like requiring some libvirt-auth meta
package, provided by libvirt-polkit und libvirt-socket would probably
do the job, but might look like over-engineering?

MfG, JBG

Hi,

I do agree that being able to go without polkit would be nice but a
similar situation with virt-manger showed that Recommends: are just not
enough. Many people skip them and then report bugs if you use Recommends
for a package that's needed in 95% of the installations. I'm just not up
to handle these.

Cheers,
 -- Guido

Hi everyone

Was upgrading one of my servers and noticed that libvirt broke completely.

Turns out, "libvirt-daemon-system" could not be installed due to "policykit-1" dependency,
which in turn depends on ...drum roll... "systemd", which is blacklisted on my systems.

Manually extracting all the stuff from the package solved this for me. But it is kinda
hacky way of doing it.

Is it at least possible to separate initscripts to a separate package, not depending on
systemd?

TIA

Dear Maintainer,

Hello,

given the recent CVE-2021-4034 (gaining local root access via "policykit-1"), I
would like to raise this request again: it would be great, if the
libvirt-daemon-system package would reduce its hard dependency ("Depends") on
"policykit-1" to a soft dependency ("Recommends").

If I understand your previous comment correctly, then this is technically
feasible (i.e. "it just works"):
I understand, that such bug reports can take effort.
But I think, the circumstances changed meanwhile (since 2015): "apt" installs
"Recommends" by default (see `apt-config dump | grep -w Recommends`), thus there
should be only very few users who are manually overriding this setting.
And I think, there is a fair chance, that these users know what they are doing.

The Debian Policy [2] also advises to use "Recommends" in this case.

Please reduce the "Depends" relationship towards "policykit-1" down to
"Recommends".

Thank you for maintaining this package!

Cheers,
Lars


[1] https://www.debian.org/security/2022/dsa-5059
[2] https://www.debian.org/doc/debian-policy/ch-relationships.html

Yes!

This bug came up in a sub-thread on debian-user, also in relation to
DSA-5059:

https://lists.debian.org/debian-user/2022/01/msg01166.html

Just in case it helps, anecdotally I can confirm that at least on
debian-user problems due to missing packages that are only Recommends:
have been both extremely rare in the past years and treated as an
unsupported configuration.

Hope this helps,
Andrei