I reviewed libblockdev version 2.16-2 as checked into bionic. This should
not be considered a full security audit but rather a quick gauge of
maintainability.

- libblockdev is a plugin-based library to work with block devices,
  providing an API based interface that knows how to either perform
  underlying operations directly or call the necessary command line
  applications as appropriate.

- There are no CVEs in our database

- Build-Depends: debhelper, libtool, dh-python, python3:any, libglib2.0-dev
  libgirepository1.0-dev, libcryptsetup-dev libdevmapper-dev libudev-dev
  libsystemd-dev, libdmraid-dev, libvolume-key-dev, libbytesize-dev,
  libnss3-dev libparted-dev libmount-dev libblkid-dev libpython3-dev,
  libkmod-dev gtk-doc-tools, gobject-introspection, pylint

- libblockdev does not itself daemonize
- no networking
- automatically generated pre/post inst/rm scripts
- no initscripts
- no dbus services
- no setuid files
- no executables in PATH
- no sudo fragments
- no udev rules
- There is a test suite; it is not run during the build. I suspect keeping
  this test suite disabled is the right approach.
- No cronjobs
- Noisy build logs, primarily from the documentation tools; not ideal, but
  at least not much from the code itself

- Several plugins execute helper tools; the glib helpers make the
  resulting code fairly complex, but it looks like the executions were
  carefully written
- memory management is careful; allocated memory is quickly freed when it
  is no longer used to simplify error handling
- normally 'files' being opened are block devices
- Logging functions looked careful
- No environment variable use
- Does not itself do cryptography -- drives LUKS, VeraCrypt, etc via
  helpers
- Does not do networking
- Does not use temporary files
- Does not use WebKit
- Does not use PolicyKit
- Does not use JavaScript
- Mostly clean cppcheck results; s390 code has legitimate errors:
  [src/plugins/s390.c:293]: (error) Used file that is not opened.
  [src/plugins/s390.c:293]: (error) Resource handle 'fd' freed twice.
  [src/plugins/s390.c:968]: (error) Resource leak: fd


The s390 code does not feel as mature as the rest of the code base.
I suspect a deeper inspection of the s390 sources would find more issues.
If it can be disabled without significant loss of functionality then I
recommend we disable it.

Security team ACK for promoting libblockdev to main.

Here's some notes I took while reviewing the code, in the hopes that they
are useful:

- bd_s390_dasd_online() double-closes fd, uses fd when it isn't open
- bd_s390_zfcp_offline() leaks fd in rc == EOF branch
- bd_s390_zfcp_online() calls fclose(fd) in a branch when fd is known to
  be NULL
- bd_s390_zfcp_scsi_offline() does not check fopen(hba_path, "r") for an
  error return
- bd_s390_zfcp_scsi_offline() does not check fopen(wwpn_path, "r") for an
  error return
- bd_s390_zfcp_scsi_offline() does not check fopen(lun_path, "r") for an
  error return

- bd_crypto_tc_open(), luks_format(), (and other functions) do not zero
  out secrets such as passwords. (This is difficult to do; the goal is not
  to be perfect, but to try. Simply adding memset_s() calls would be a
  step in the right direction.)

- Many routines in src/plugins/crypto.c call strlen(passwd), some other
  functions are described as taking binary data in password parameters. Is
  there a chance of one interface setting, changing, or removing a
  password, that other interfaces cannot work with?

- write_escrow_data_file() writes what looks like a secret key equivalent
  to a file but does not itself set a safe umask before doing so.


Thanks


** Changed in: libblockdev (Ubuntu)
     Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to udisks2 in Ubuntu.
https://bugs.launchpad.net/bugs/1735499

Title:
  [MIR] libblockdev

Status in libblockdev package in Ubuntu:
  New
Status in udisks2 package in Ubuntu:
  New

Bug description:
  Availability
  ============
  Built for all supported architectures. In sync with Debian.

  Rationale
  =========
  udisks2 2.7 uses the "libblockdev library for all low level storage 
management tasks instead of calling command line tools." libblockdev appears to 
have the same maintainers ("storaged project") as udisks2.

  It would be nice to have the new version to support GNOME Disks 3.26's new 
Resize and Repair features.
  http://pothos.blogsport.eu/2017/08/22/last-project-phase-and-3-26-features/

  There is some interest in dropping Gparted from the Ubuntu live ISO
  since it does not support Wayland and it still uses gtk2.

  Security
  ========
  No known security issues

  https://security-tracker.debian.org/tracker/source-package/libblockdev
  https://launchpad.net/ubuntu/+source/libblockdev/+cve

  Quality assurance
  =================
  - Ubuntu Desktop bugs is the subscriber (although the Desktop Team thinks 
that Foundations should be responsible for udisks and friends)

  https://bugs.launchpad.net/ubuntu/+source/libblockdev
  https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libblockdev
  https://github.com/storaged-project/libblockdev/issues

  dh_auto_test is run but I guess it's not actually running the upstream test 
suite yet. (I think the upstream test suite needs to be run as autopkgtests)
  See http://storaged.org/libblockdev/ch03.html

  No autopkgtests

  Dependencies
  ============
  Debian's udisks2 recommends libblockdev-plugins-all which depends on these 
binary packages:
  - libblockdev-crypto2 which depends on the universe libvolume-key1 (source: 
volume-key)
  - libblockdev-btrfs2 which depends on the universe libbytesize1 (source: 
libbytesize)
  - libblockdev-kbd2 which depends on the universe libbytesize1 (source: 
libbytesize)
  - libblockdev-mdraid2 which depends on the universe libbytesize1 (source: 
libbytesize)

  libbytesize is another storaged project. Neither libbytesize nor
  volume-key have any other universe binary dependencies. It might be ok
  to temporarily not recommend those udisks2 plugins until the other 2
  MIRs are processed.

  Standards compliance
  ====================
  4.1.1, debhelper compat 10, simple dh7 style rules

  Maintenance
  ===========
  Maintained in Debian by the Debian Utopia team, which is a small team focused 
on cross-desktop freedesktop.org stuff.

  upstream:
  https://github.com/storaged-project/libblockdev

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libblockdev/+bug/1735499/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to