© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
I reviewed usbguard 0.7.4+ds-1 as checked into eoan. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
usbguard consists of a daemon which manages the authorization of new USB
devices via udev events. It provides an IPC interface (which by default is
only accessible by the root user but the Debian packaging adds the wheel
and usbguard groups) which allows it to be controlled - this uses protobuf
for serialization. A separate daemon, usbguard-dbus provides an interface
over the DBus system bus which uses PolicyKit to ensure only administrator
users can access privileged methods (such as authorizing new devices or
changing the overall policy etc). Also provides an audit backend so that it
can provide audit events. Includes support for restricting itself with a
built-in seccomp policy which is enabled in the Debian package.
A separate binary usbguard provides a CLI to interact with the daemon via
the IPC interface.
Finally, a separate binary package, usbguard-applet-qt provides a GUI to
control the daemon using it's own IPC interface. Users who use the applet
are assumed to be in the wheel or usbguard groups to enable them to control
the daemon.
- CVE History:
- None
- Build-Depends
- Huge list including Qt, GLib, DBus, PolicyKit, libseccomp, libaudit and
docbook,
- pre/post inst/rm scripts
- postinst creates empty copies of and fixes permissions on
/etc/
is only accessible by the owner
- Is this normal? I note this is flagged as a WARNING in csp-source.txt
by uaudit.
- postrm removes the above two configuration files and the configuration
dir /etc/usbguard if empty.
- init scripts
- None
- systemd units
- usbguard daemon system service - runs usbguard-daemon with the default
configuration and restarts on failure
- usbguard-dbus system service - runs usbguard-dbus on DBus system bus
with restart on failure
- dbus services
- org.usbguard.system service
- provides an interface to interact with
- setuid binaries
- None
- binaries in PATH
- /usr/bin/usbguard
- /usr/sbin/
- /usr/sbin/
- sudo fragments
- None
- udev rules
- None
- unit tests
- Includes some unit tests which run during the build
- No autopkgtests
- cron jobs
- None
- Build logs:
- No significant warnings / errors in the build log
- Processes spawned
- usbguard watch command supports spawning a process as specified on the
command-line - so no direct chance for shell command-injection here
- Memory management
- There is not a lot of dynamic memory management - what there is appears
to be quite clean and careful
- File IO
- The configuration file for the daemon is read carefully and the path to
this is hardcoded if NOT overridden by a command-line parameter
- Files in sysfs are written to to authorize devices
- umask is defensively set even though in general not many files are
created by usbguard.
- Logging
- Logging is careful
- Environment variable usage
- Uses USBGUARD_DEBUG to enable more logging output
- USBGUARD_
configuration
- Use of privileged functions
- None
- Use of cryptography / random number sources etc
- None
- Use of temp files
- None
- Use of networking
- None
- Use of WebKit
- None
- Use of PolicyKit
- Provides a PolicyKit policy to constrain access to the DBus interface -
this looks sane
- No significant cppcheck results.
- No significant Coverity results.
Overall the code is quite clean and with no CVE history and no significant
issues noted during this security review. One question is do we just promote the
usbguard package itself to main or do we include the usbguard-applet-qt
package as well since until the GNOME integration lands (see
https:/
others) this has no user visible front-end to control it without the applet.
Security team ACK for promoting usbguard to main once the ownership of the
package is resolved and the various other issues identified in comment:4
above are addressed in some way.