Comment 7 for bug 1745455

Seth Arnold (seth-arnold) wrote :

I reviewed fprintd version 0.8.0-2 as checked into cosmic. This isn't a
full security audit but rather a quick gauge of maintainability.

- fprintd is a dbus interface for libfprint
- No CVEs in our database

- Build-Depends: debhelper, libfprint-dev, libglib2.0-dev,
  libdbus-glib-1-dev, libpolkit-gobject-1-dev, gtk-doc-tools, intltool,
  libpam0g-dev, rename

- No cryptography
- No networking
- Does DBus communication
- Does not itself daemonize, uses systemd unit file to start
- pre/post inst/rm scripts manage systemd unit, pam-auth-update, dbus
- No init scripts
- Systemd unit file has some hardening
- No setuid files
- fprintd-delete fprintd-enroll fprintd-list fprintd-verify binaries in
- No sudo fragments
- No udev rules
- Some tests but they don't appear to be run during the build
- Some surprising errors in build logs that don't appear to fail the build
  -- including Lintian run failure, make check appears to have failed too
  -- I suspect this package still needs work
- No subprocesses spawned
- Memory management is typical for glib / dbus code with type punning,
  "classes", etc. I believe I found several memory leaks but it's
  difficult to know since control flow isn't obvious.
- Filenames constructed with usernames; safety of the system relies upon
  usernames including /../ being forbidden, etc.
- No logging errors spotted
- PAM module and root-powers daemon, somewhat privileged as a result
- No environment variable use
- No networking
- No cryptography
- No sql
- No temporary files
- No WebKit
- Polkit integration, no errors spotted
- Clean cppcheck

_fprint_device_check_for_username() appears to leak client_username if
execution continues beyond _fprint_device_check_polkit_for_action()

file_storage_print_data_save() appears to leak buf if
g_mkdir_with_parents() fails

fprint_device_finalize() appears to clean up after only one of nine
probably-owned pieces of data

This codebase is similar to most dbus / glib code -- no obvious flow
through the program, type punning, layers of abstraction, etc. Individual
methods look fine but it's harder to get a feel for the overall program
layout. The possible memory leaks may represent real problems if they can
be triggered on-demand by users.

It's important to note that security team considers fingerprints to be
akin to usernames and not passwords. Any potential issues with this tool
will be treated with this threat model in mind.

At last check the security team does not have supported hardware. We will
rely upon the Desktop team to provide testing when updates are needed.

Security team ACK for promoting fprintd to main.