© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
[Duplication]
Function-wise there seems to be usbauth and usbguard (thanks Seth and Jamie for adding your early experiences).
None of them is in main yet so it would be no duplication.
Picking among the two projects can be hard as they promise almost the same.
But in terms of upstream activity, commits, forks and all that USBGuard seems to win over USBAuth for now.
Therefore the choice between those to seems to be made by the community.
[Embedded sources and static linking]
- no embedded code of other projects
- it builds a static library, but that is only used for tests (make check) and not in the binary files
- no golang
[Security]
- history of CVEs = no CVEs yet
- does not use webkit1,2
- does not use lib*v8 directly
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrates arbitrary javascript into the desktop
- does not deals with system authentication (eg, pam), etc)
Not so good
- runs a daemon as root
- parses data formats (it has a API on dbus)
- opens a port (well a Dbus listener to be specific)
- the program deals with (device) authentication
A few open bugs indicate known security issues which should be
fixed before promotion:
https:/
https:/
Therefore this will need an in depth security review for sure.
[Common blockers]
- builds fine at the moment
- test suite runs on build
- no python code
- translations are in src/GUI.Qt/...
Not so good:
- No autopkgtest (e.g. if kernel USB handling breaks it)
OTOH hard to implement as you need to fake USB devices (maybe qemu can help).
There is in 7.3 a "umockdev based device manager capable of simulating
devices based on umockdev-record files"
- The Team (according to the report) has a bug subscriber (security),
Security might be subscribed, but I don't think they own/maintain the package.
They might just be subscribed just for watching, I think Desktop will need to
own this one if we promote it (up for discussion between security and desktop).
[Packaging red flags]
- no Ubuntu delta
- watch file present
- upstream as well as Debian seems regular and active in regard to updates
- Lintian is ok with the package
- d/rules seems to be short an easy
- not using Built-Using
- no golang package
Not so good:
- lacks symbols tracking for libusbguard.so.0
- the current release (since July last year) 7.4 is not yet packaged
[Upstream red flags]
- bugs are 5 Debian, 5 Ubuntu and 60 open / 142 closed upstream
- no usage of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no Dependency on webkit, qtwebkit, seed or libgoa-*
- no Embedded source copies
Not so good - is the status on open bug in general atm:
- there are a few crashes in the Ubuntu bug tracker and as we
learned crashing the daemon means disconnected devices.
- The upstream bug tracker has two concerning bugs that might need to be
addressed before promoting it being
https:/
https:/
- build has a concerning warning
dpkg-shlibdeps: warning: debian/
That is concerning as in this case it is not meant to be a plugin.
Missing dependency?
As also outlined by jdstrand in comment #2 the design of usbguard has a central daemon which can be an issue if it crashes.
There were issues about it in the past [1] and there will be more, as well as crash reports just being yet unknown [2] so far.
If it could be implemented that a dying daemon will not mean un-attachable devices, that might be great.
So the Desktop team needs to think twice about maintaining and enabling it, maybe make it an opt in for a while and do some quite rigorous testing?
[1]: 200~https:/
[2]: https:/
An example use case that might be related to jdstrands plug/unplug/plug issues is for example this:
# all devices are set to be allowed
$ sudo usbguard list-devices -b
# The setup is laptop -> USB switch (to have keyboard/mouse on two systems) -> keyboard/mouse
# toggle the switch makes these devices get new IDs which is wrong as they are the same devices
$ sudo usbguard list-devices -b
21: block id 1a40:0101 serial "" name "USB 2.0 Hub" hash "xe96rjr8V53Jw+
$ sudo usbguard allow-device 21
$ sudo usbguard list-devices -b
22: block id 046d:c069 serial "" name "USB Laser Mouse" hash "jsWZtKXHLV3Xw9
23: block id 046d:c318 serial "" name "Logitech Illuminated Keyboard" hash "Daax74uu16pKpA
$ sudo usbguard allow-device 22
$ sudo usbguard allow-device 23
# This repeats and makes it unusable
# The IDs really change in the kernel, but usbguard should detect that
# via e.g. vendor/produc IDs or anything like it
# I'd recommend testing and fixing any of such common cases and until then
# at least not make this a default install.
List of TODOs that I found
(not necessarily complete, some recommended some required):
- Change the current on-install default to block all but host controllers
to "allow all that is attached on install".
That can either be done in a postinst or by changing the base
PresentDevice
- to avoid a install hickup maybe even set PresentDevicePo
set all to be allowed and only then reset to "apply-policy"
- set IPCAllowedGroup
- Fix plug/unplug/plug issues
- other cleanups like the pkg-config not being installed, adding symbols
tracking, new version, ... (just a general packaging polish)
- fix the pthread dependency, libusbguard0 is not a plugin
- fix the (referred above) important kown bug issues
- implementing an autopkgtest might be required (see current issues with linux 5.0 upstream)
=> This is in RHEL7.4 and later, maybe they already have tweaks to such things that could be leveraged?
[Summary]
From a formal POV there is no blocker for the MIR, but it will need
a) need a formal security review
b) recommend some extra testing and commitment by the owning team
c) some polishing to be consumable&reliable on the usual Ubuntu level would be nice
I'm somewhat torn to shove that onto the security teams queue already.
My verdict for now is to ask the Desktop team to really look at testing/fixing all the findings again.
If the result of this is a program that the Desktop team explicitly wants to own then please state so and we can continue with the security review.
But it feels that the outcome might as well be "well now that I know that - no thanks".
=> Nack until packaging, known issues and testing improved and we got an explicit "yes subscribe to the package and we want to own it that way" from the Desktop team.
Setting incomplete for now.