Debian Bug report logs - #928032
Default configuration for USBGuard

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Thiébaud Weksteen <tweek@google.com>

To: submit@bugs.debian.org

Subject: Default configuration for USBGuard

Date: Fri, 26 Apr 2019 15:10:19 +0200

Package: usbguard
Version: 0.7.4+ds-1
Severity: wishlist

By default, USBGuard is shipped with a configuration that blocks any
USB device. This has for effect that some users ended up locking
themselves out when installing the package (as reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908037). The
solution adopted to fix this bug was to not enable nor start the
service at installation time. As a result, once configured, a user
would have to enable the service manually. This is problematic for
other packages that relies on USBGuard as a dependency. It would be
easier to have the service started with a sane configuration. The
options are:

1. Change ImplicitPolicyTarget=allow, to allow all devices by default
(least secure).
2. Change PresentDevicePolicy=allow (or keep), this only allows
devices that are already plugged in when the service starts (this
would still solve the bug mentioned above).
3. (idea suggested by Birger) Generate and store the list of currently
connected devices at install time (using usbguard generate-policy)
4. (idea suggested by Birger) Have a dialog at install time to let the
user decide on the value of ImplicitPolicyTarget (or
PresentDevicePolicy).

Related to the issue, upstream has explicitly mentioned that this
decision belongs to the distribution:
https://github.com/USBGuard/usbguard/pull/267#issuecomment-454710391.

Does anyone have any preference?

Thanks,
Thiebaud

Message #10 received at 928032@bugs.debian.org (full text, mbox, reply):

From: Thiébaud Weksteen <tweek@google.com>

To: 928032@bugs.debian.org

Subject: Re: Default configuration for USBGuard

Date: Fri, 7 Jun 2019 11:08:32 +0200

This may be relevant to the discussion, from the Debian Policy Manual

3.9.1. Prompting in maintainer scripts
"If a package has a vitally important piece of information to pass to
the user (such as “don’t run me as I am, you must edit the following
configuration files first or you risk your system emitting
badly-formatted messages”), it should display this in the config or
postinst script and prompt the user to hit return to acknowledge the
message."

Adding a config to let the user decide if the service should be
enabled and started seems to be the easiest option.

Thiébaud

Message #15 received at 928032@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: Thiébaud Weksteen <tweek@google.com>, 928032@bugs.debian.org

Subject: Re: Bug#928032: Default configuration for USBGuard

Date: Wed, 19 Jun 2019 20:36:12 -0400

On Fri, Apr 26, 2019 at 03:10:19PM +0200, Thiébaud Weksteen wrote:
> Does anyone have any preference?

I think minimizing the number of prompts to the user would be
preferable, honestly.

I would do the following changes in the Debian package:

 1. PresentDevicePolicy=keep - just to avoid breaking existing setups
    will still providing *some* security for new devices (although the
    rule generation thing does that, this is easier to implement in the
    Debian package). Note that I am not clear on the difference between
    =keep and =allow, so take this with a grain of salt. Upstream says
    this is preferably kept to apply-policy because an attacker might
    crash the USBguard daemon to get their device rejected, but I'm not
    sure it's that much of a threat model.

 2. Add `plugdev` to the IPCAllowedGroups setting. It's commonly the
    group that is allowed to deal with pluggable devices, and it's not a
    big compromise to allow them to decide what gets plugged in or not.
    This ensures that normal users can interact with the USBguard daemon
    and do stuff in case the above fails.

I think enforcing new devices confirmation then becomes safe enough and
meaningful, without having to otherwise prompt the user.

A.

Message #20 received at 928032@bugs.debian.org (full text, mbox, reply):

From: Birger Schacht <birger@rantanplan.org>

To: Antoine Beaupre <anarcat@debian.org>, 928032@bugs.debian.org, Thiébaud Weksteen <tweek@google.com>

Subject: Re: Bug#928032: Default configuration for USBGuard

Date: Fri, 12 Jul 2019 18:56:29 +0200

Hi,

I'm currently working on packaging the 0.7.5 release of usbguard, which
was released a little more than a week ago. I have looked at the various
options we have to tackle the default configuration.

I agree that the prompts at installation time should be minimized, so
I'm not convinced of my initial idea of asking the user for the value of
ImplicitPolicyTarget et al anymore. Setting ImplicitPolicyTarget to
allow by default seems wrong to me- it would mean users would have to
manually configure the service to actually do what it is intended to do.

I was torn between the solution to generate a policy and setting
PresentDevicePolicy to `keep`. For now, I have configured the package to
generate a rules file using `usbguard generate-policy` if no rules file
exists - and I will also reenable the service. Thats also what upstream
suggests in the bug report mentioned by Thiébaud. But I am open to
change that to the PresentDevicePolicy solution if there happen to come
up problems with that default configuration.

Thanks Antoine also for the information about the `plugdev` group, I'll
add a patch adding that group to the IPCAllowedGroups setting.

cheers,
Birger

Message #25 received at 928032@bugs.debian.org (full text, mbox, reply):

From: Thiébaud Weksteen <tweek@google.com>

To: Birger Schacht <birger@rantanplan.org>

Cc: Antoine Beaupre <anarcat@debian.org>, 928032@bugs.debian.org

Subject: Re: Bug#928032: Default configuration for USBGuard

Date: Mon, 15 Jul 2019 11:09:55 +0200

Hi Birger, Antoine,

Thanks for getting 0.7.5 ready. For the difference between "allow" and
"keep" on PresentDevicePolicy, the standard use case is handled
similarly (i.e., user installing USBGuard for the 1st time, no
customisation). The difference is slightly more subtle for hosts that
have changed the sysfs attributes directly, for some reason. In this
case, "keep" would respect whatever state was declared. Because of
this and as Antoine suggested, I think this is a better option.

On generate-policy vs PresentDevicePolicy, I would argue that the
simplest option is the best. By running generate-policy, you are
parsing all current devices, generating rules and then applying these
rules. There might be (unlikely) a bug in the rule generation which
ends up blocking a device (e.g., missing attribute or so). The
PresentDevicePolicy=keep is just a simpler alternative.

It might be useful to write down some Debian-specific documentation on
how to setup the daemon to be more restrictive? The wiki might be a
good place for that?

Thanks,
Thiébaud


On Fri, Jul 12, 2019 at 6:56 PM Birger Schacht <birger@rantanplan.org> wrote:
>
> Hi,
>
> I'm currently working on packaging the 0.7.5 release of usbguard, which
> was released a little more than a week ago. I have looked at the various
> options we have to tackle the default configuration.
>
> I agree that the prompts at installation time should be minimized, so
> I'm not convinced of my initial idea of asking the user for the value of
> ImplicitPolicyTarget et al anymore. Setting ImplicitPolicyTarget to
> allow by default seems wrong to me- it would mean users would have to
> manually configure the service to actually do what it is intended to do.
>
> I was torn between the solution to generate a policy and setting
> PresentDevicePolicy to `keep`. For now, I have configured the package to
> generate a rules file using `usbguard generate-policy` if no rules file
> exists - and I will also reenable the service. Thats also what upstream
> suggests in the bug report mentioned by Thiébaud. But I am open to
> change that to the PresentDevicePolicy solution if there happen to come
> up problems with that default configuration.
>
> Thanks Antoine also for the information about the `plugdev` group, I'll
> add a patch adding that group to the IPCAllowedGroups setting.
>
> cheers,
> Birger

Message #30 received at 928032@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Thiébaud Weksteen <tweek@google.com>, Birger Schacht <birger@rantanplan.org>

Cc: 928032@bugs.debian.org

Subject: Re: Bug#928032: Default configuration for USBGuard

Date: Tue, 16 Jul 2019 06:47:14 -0400

On 2019-07-15 11:09:55, Thiébaud Weksteen wrote:
> Hi Birger, Antoine,
>
> Thanks for getting 0.7.5 ready. For the difference between "allow" and
> "keep" on PresentDevicePolicy, the standard use case is handled
> similarly (i.e., user installing USBGuard for the 1st time, no
> customisation). The difference is slightly more subtle for hosts that
> have changed the sysfs attributes directly, for some reason. In this
> case, "keep" would respect whatever state was declared. Because of
> this and as Antoine suggested, I think this is a better option.
>
> On generate-policy vs PresentDevicePolicy, I would argue that the
> simplest option is the best. By running generate-policy, you are
> parsing all current devices, generating rules and then applying these
> rules. There might be (unlikely) a bug in the rule generation which
> ends up blocking a device (e.g., missing attribute or so). The
> PresentDevicePolicy=keep is just a simpler alternative.
>
> It might be useful to write down some Debian-specific documentation on
> how to setup the daemon to be more restrictive? The wiki might be a
> good place for that?

Problem with PresentDevicePolicy=keep is that it might break on reboot
or setup changes (e.g. moving laptop from office to home).

That said, I'd expect such docs to live in
/usr/share/doc/usbguard/README.Debian or something similar, that way if
my USB ethernet controller gets blockd, i can still read it. :) But wiki
is also good because people can contribute more easily.

Either way, docs are good. :) And one can point to the other.

a.
-- 
On ne peut s'empêcher de vieillir, mais on peut s'empêcher de devenir
vieux.
                        - Henri Matisse

Message #35 received at 928032@bugs.debian.org (full text, mbox, reply):

From: Birger Schacht <birger@rantanplan.org>

To: Antoine Beaupré <anarcat@debian.org>, Thiébaud Weksteen <tweek@google.com>

Cc: 928032@bugs.debian.org

Subject: Re: Bug#928032: Default configuration for USBGuard

Date: Tue, 16 Jul 2019 18:16:36 +0200

Hi,

On 7/16/19 12:47 PM, Antoine Beaupré wrote:
> On 2019-07-15 11:09:55, Thiébaud Weksteen wrote:

>> On generate-policy vs PresentDevicePolicy, I would argue that the
>> simplest option is the best. By running generate-policy, you are
>> parsing all current devices, generating rules and then applying these
>> rules. There might be (unlikely) a bug in the rule generation which
>> ends up blocking a device (e.g., missing attribute or so). The
>> PresentDevicePolicy=keep is just a simpler alternative.
>>
>> It might be useful to write down some Debian-specific documentation on
>> how to setup the daemon to be more restrictive? The wiki might be a
>> good place for that?
> 
> Problem with PresentDevicePolicy=keep is that it might break on reboot
> or setup changes (e.g. moving laptop from office to home).

You mean that usbguard doesn't honor the rules when it is started on
boot? That would be my fear- because the default from the kernel is to
allow devices and if we set PresentDevicePolicy to keep, it doesn't look
at the rules defined in the rules file at boot time. That means if I
forbid a device, after the next reboot the device would be allowed.

cheers,
Birger

Message #40 received at 928032@bugs.debian.org (full text, mbox, reply):

From: Thiébaud Weksteen <tweek@google.com>

To: Birger Schacht <birger@rantanplan.org>

Cc: Antoine Beaupré <anarcat@debian.org>, 928032@bugs.debian.org

Subject: Re: Bug#928032: Default configuration for USBGuard

Date: Tue, 16 Jul 2019 19:01:35 +0200

It might be worth talking about what threat we want to address in the
default config. In both cases (keep or generate-policy), the kernel
will be exposed until usbguard is started. If we are considering an
attacker using a malicious device to target some kernel driver, either
solution is affected.

In the case of generate-policy, we would prevent further attack
surface (e.g., if the user has automount enabled in their GUI).
However, I still think that the "keep" option is more conservative and
therefore less likely to block a device inadvertently. It may also be
easier to explain the setup to the user: "any new USB device inserted
after the daemon started will be blocked" compared to "we have taken a
snapshot of the devices currently connected, any other device will be
blocked after the daemon starts".

I've started https://wiki.debian.org/USBGuard. I'll keep editing this
page based on our conversation here.

Thanks

On Tue, Jul 16, 2019 at 6:16 PM Birger Schacht <birger@rantanplan.org> wrote:
>
> Hi,
>
> On 7/16/19 12:47 PM, Antoine Beaupré wrote:
> > On 2019-07-15 11:09:55, Thiébaud Weksteen wrote:
>
> >> On generate-policy vs PresentDevicePolicy, I would argue that the
> >> simplest option is the best. By running generate-policy, you are
> >> parsing all current devices, generating rules and then applying these
> >> rules. There might be (unlikely) a bug in the rule generation which
> >> ends up blocking a device (e.g., missing attribute or so). The
> >> PresentDevicePolicy=keep is just a simpler alternative.
> >>
> >> It might be useful to write down some Debian-specific documentation on
> >> how to setup the daemon to be more restrictive? The wiki might be a
> >> good place for that?
> >
> > Problem with PresentDevicePolicy=keep is that it might break on reboot
> > or setup changes (e.g. moving laptop from office to home).
>
> You mean that usbguard doesn't honor the rules when it is started on
> boot? That would be my fear- because the default from the kernel is to
> allow devices and if we set PresentDevicePolicy to keep, it doesn't look
> at the rules defined in the rules file at boot time. That means if I
> forbid a device, after the next reboot the device would be allowed.
>
> cheers,
> Birger

Message #45 received at 928032@bugs.debian.org (full text, mbox, reply):

From: Birger Schacht <birger@rantanplan.org>

To: Thiébaud Weksteen <tweek@google.com>, 928032@bugs.debian.org

Cc: Antoine Beaupré <anarcat@debian.org>

Subject: Re: Bug#928032: Default configuration for USBGuard

Date: Sun, 21 Jul 2019 10:19:56 +0200

Hi,

On 7/16/19 7:01 PM, Thiébaud Weksteen wrote:
> It might be worth talking about what threat we want to address in the
> default config. In both cases (keep or generate-policy), the kernel
> will be exposed until usbguard is started. If we are considering an
> attacker using a malicious device to target some kernel driver, either
> solution is affected.
> 
> In the case of generate-policy, we would prevent further attack
> surface (e.g., if the user has automount enabled in their GUI).
> However, I still think that the "keep" option is more conservative and
> therefore less likely to block a device inadvertently. It may also be
> easier to explain the setup to the user: "any new USB device inserted
> after the daemon started will be blocked" compared to "we have taken a
> snapshot of the devices currently connected, any other device will be
> blocked after the daemon starts".

I think the fact that usbguard (with the PresentDevicePolicy set to
`keep`) allows devices the user has explicitly configured to be
forbidden is a bug- I have filed
https://github.com/USBGuard/usbguard/issues/314 to address this. (I
think thats especially problematic since the user is not informed that
their rule is ignored).
I think when the `keep` policy honors the rules file it is safe to
change the default of PresentDevicePolicy to `keep`.


> I've started https://wiki.debian.org/USBGuard. I'll keep editing this
> page based on our conversation here.
Thanks, I'll also add a REAME to the debian package.

cheers,
Birger

Message #50 received at 928032@bugs.debian.org (full text, mbox, reply):

From: Thiébaud Weksteen <tweek@google.com>

To: Birger Schacht <birger@rantanplan.org>

Cc: 928032@bugs.debian.org, Antoine Beaupré <anarcat@debian.org>

Subject: Re: Bug#928032: Default configuration for USBGuard

Date: Thu, 25 Jul 2019 15:53:47 +0200

On Sun, Jul 21, 2019 at 10:20 AM Birger Schacht <birger@rantanplan.org> wrote:
>
> Hi,
>
> On 7/16/19 7:01 PM, Thiébaud Weksteen wrote:
> > It might be worth talking about what threat we want to address in the
> > default config. In both cases (keep or generate-policy), the kernel
> > will be exposed until usbguard is started. If we are considering an
> > attacker using a malicious device to target some kernel driver, either
> > solution is affected.
> >
> > In the case of generate-policy, we would prevent further attack
> > surface (e.g., if the user has automount enabled in their GUI).
> > However, I still think that the "keep" option is more conservative and
> > therefore less likely to block a device inadvertently. It may also be
> > easier to explain the setup to the user: "any new USB device inserted
> > after the daemon started will be blocked" compared to "we have taken a
> > snapshot of the devices currently connected, any other device will be
> > blocked after the daemon starts".
>
> I think the fact that usbguard (with the PresentDevicePolicy set to
> `keep`) allows devices the user has explicitly configured to be
> forbidden is a bug- I have filed
> https://github.com/USBGuard/usbguard/issues/314 to address this. (I
> think thats especially problematic since the user is not informed that
> their rule is ignored).
> I think when the `keep` policy honors the rules file it is safe to
> change the default of PresentDevicePolicy to `keep`.
>

Right, I see. I would argue this is not a bug but work as intended
(the intent of the apply-policy settings was clearly an apply-rules
more than anything).
If this is the behaviour you really want, then generating the policy
and leaving PresentDevicePolicy to apply-policy makes more sense. I'm
ok with that option.

>
> > I've started https://wiki.debian.org/USBGuard. I'll keep editing this
> > page based on our conversation here.
> Thanks, I'll also add a REAME to the debian package.
>
> cheers,
> Birger

Message #55 received at 928032-close@bugs.debian.org (full text, mbox, reply):

From: Birger Schacht <birger@rantanplan.org>

To: 928032-close@bugs.debian.org

Subject: Bug#928032: fixed in usbguard 0.7.5+ds-1

Date: Fri, 04 Oct 2019 08:49:20 +0000

Source: usbguard
Source-Version: 0.7.5+ds-1

We believe that the bug you reported is fixed in the latest version of
usbguard, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 928032@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Birger Schacht <birger@rantanplan.org> (supplier of updated usbguard package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Fri, 26 Jul 2019 18:52:01 +0200
Source: usbguard
Binary: libusbguard0 usbguard
Architecture: source
Version: 0.7.5+ds-1
Distribution: unstable
Urgency: medium
Maintainer: Birger Schacht <birger@rantanplan.org>
Changed-By: Birger Schacht <birger@rantanplan.org>
Description:
 libusbguard0 - USB device authorization policy framework - shared library
 usbguard   - USB device authorization policy framework
Closes: 846400 923542 928032 931381
Changes:
 usbguard (0.7.5+ds-1) unstable; urgency=medium
 .
   * New upstream version 0.7.5 (Closes: #923542)
     The upstream source does not contain the qt applet anymore.
    + Remove usbguard-applet-qt package and qt build dependencies
      from d/control
    + Remove qt specific lines from d/rules
    + Remove applet .desktop and .install files from debian/
      directory
    + Remove stale copyright paragraphs from d/copyright
    + d/upstream/signing-key.asc: Update upstreams signing key to
      0xEF3F1EF2C1D2077F4BD74BC1F0B58180D5CD7168
    + d/patches/disable-002_cli_devices.patch: Update patch
 .
   * d/usbguard.install: Use more placeholders to make file more
     readable and add zsh completion file
 .
   * d/usbguard.postinst: generate initial policy on install using
     `usbguard generate-policy` and enable `plugdev` access using
     IPC ACLs
 .
   * d/rules
    + Add dh_install override to ease package maintaince
      (it lists files in debian/tmp)
    + Remove void configure flag
    + Add -pthread to LDFLAGS (Closes: #931381)
    + Reenable and start systemd services on install, now that there
      is an initial rules file being generated (Closes: #928032)
 .
   * d/control
    + Add libumockdev build dependency, enable ldap support
      by adding libldap2-dev build dependency
    + Bump debhelper to version 12, replace the build dependency
      with debhelper-compat and remove the d/compat file
    + Update the homepage URL
    + Add rules-requires-root: no
    + Bump standards version to 4.4.0
    + Add a Breaks relationship for the applet, that is not shipped
      with usbguard anymore
 .
   * Add init scripts for usbguard-dbus and usbguard (Closes: #846400)
 .
   * d/patches
    + Rename change-ipc-allowedgroup.patch to
      0001-Set-IPCAllowedGroups-to-root-plugdev.patch and add the plugdev
      group to the list of groups allowed to use the IPC interface
    + Patch systemd service file to allow write access to rules file and
      fix IPC ACLs
      0004-Patch-ReadWritePaths-and-CapabilityBoundingSet.patch
 .
   * d/gitlab-ci.yml: switch to the salsa-ci-team pipeline
 .
   * d/usbguard.README.Debian: add a Debian specific README with the
     most basic instructions
 .
   * d/usbguard-daemon.conf: remove modified config file, as we are using
     the upstream one since a few versions
Checksums-Sha1:
 8512d3d75f7edf9984449c236a283d58781dd420 2333 usbguard_0.7.5+ds-1.dsc
 e0b10b332ad4d349ba11254b17dff3e647777174 664375 usbguard_0.7.5+ds.orig.tar.gz
 c13bb119f44b1277ba0f90798947165df8d58774 19032 usbguard_0.7.5+ds-1.debian.tar.xz
 9a3c77735edfac5cfa1f1d8f24744fe27a96d061 9049 usbguard_0.7.5+ds-1_source.buildinfo
Checksums-Sha256:
 fb96b5118cac231a9e6d35e25f3bdca5afe76f9da51ff9d0c346b52f63ced880 2333 usbguard_0.7.5+ds-1.dsc
 2213a9c34e62a0f430b6e99710325defc97a2320edab85432e8ce0599a4a36f4 664375 usbguard_0.7.5+ds.orig.tar.gz
 bec585304173f6ac8897c16e85fb5d5957dfa0117cf4fa5b380f1fd7b00ea1d9 19032 usbguard_0.7.5+ds-1.debian.tar.xz
 840c15a850d5e18bfd6af511222f86da45185e3c7a30642bd5cb893142460d01 9049 usbguard_0.7.5+ds-1_source.buildinfo
Files:
 62520ef59789c8c0ea42a830208da64c 2333 utils optional usbguard_0.7.5+ds-1.dsc
 6d92eda88de553e53eca060b5905eb68 664375 utils optional usbguard_0.7.5+ds.orig.tar.gz
 db0417f68ca9e76e81d82ad97f057dcc 19032 utils optional usbguard_0.7.5+ds-1.debian.tar.xz
 ac3149a9131f97ece636737adc3df1ca 9049 utils optional usbguard_0.7.5+ds-1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE7eP0RD800mGVFNeQsUuww42GHPEFAl2XArQACgkQsUuww42G
HPHREg//ZI/YcJy3pAXiAdFYkGbBT1Iy9Onw5OfZNG/b2KdO24bie8Q3yszKRBVB
I5StbJS3u+ewoQTXeBl/41LFYnXkb5xmxnenCEl4thsF+x0ajXsvRg/kgEVtz7Dq
adV8pAI/AdaZOtq0T0zRWSEAP/7qb5/+cOTrFWcbD7ErD8ZJauCr5+4YCtGxy5fI
h4HgyBGZYm3+bW9TUSapBprGo+G17CFzTkXGMesetfrFVjskCEKfT3oZdC0Ezrx+
+pQxGIZbzkgvdaJGOhDzyNIecotLb3GuzTFMERe5hD7jGhqLWKVlPPIaT7OMmxgx
M80w7CRs+kGE8UKdxUBMg1tVeaccz08J4yQ7UNmjmL0csB6EgptIIWB4J3nOpcrM
Ihzde2gVIeflXpYV3y5AEhTiocFpAHYt9CtNOf6MBDol8rFKLLQkOMouVnE5IuZn
yxo79sSmBFK9hIYQABZBXy5nUM6q4HHUSTZsj1HjuFVNuYWvDPy2B4VtSR+1uUaN
L98EpGRRh1baXsCFWSVQH2bCKZImf0OF9n9gvp9rYMEbjOWHl+rEnDX6yqPWwQ7T
YYb9XNfg+fLTqd/dtMVQszjhNDrVnCc5BG1DcB1EAGzyHQHaGsjueNPIxbEInXXF
TsjrkzfwXO7b+FzjTRadXtHvzocEt/smgs2Dy5vyVTIY9LBosMU=
=R1sw
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.