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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1735499 Title: [MIR] libblockdev To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libblockdev/+bug/1735499/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs