I reviewed masakari 9.0.0~b2~git2020020609.8b122a8-0ubuntu2 as checked into
focal. This shouldn't be considered a full audit but rather a quick gauge
of maintainability.
masakari is a OpenStack component providing a high availability service for
instances - this allows KVM-based virtual machine instances to be restarted
automatically in the event of failure.
- No CVE History
- No particularly security relevant Build-Depends
- apache2-dev, debhelper, dh-apache2, dh-python, openstack-pkg-tools,
python3-all, python3-setuptools, python3-sphinx,
- pre/post inst/rm scripts
- A bunch of automatically added scripts (from dh_apache2, dh_python3,
dh_systemd_enable, dh_installinit) to setup apache site config etc for
the API endpoint, compile python code and setup systemd units /
initscript appropriately
- postinst to add masakari group and user and ensure directories and
databases etc are owned by the masakari user/group
- NOTE: there appears to be a typo in the postinst script which uses
chmod instead of chown:
- chmod masakari:masakari /var/lib/masakari/masakari.sqlite
- ^^^^^ should this be chown instead?
- init scripts
- Simple init script to declare the masakari-engine and then uses
openstack-pkg-tools to automatically generate the rest
- systemd units
- Simple service to call out to the init script to start directly but
managed by systemd as a service
- No dbus services
- No setuid binaries
- python3-masakari provides the following binaries in PATH
- /usr/bin/masakari-api
- /usr/bin/masakari-engine
- /usr/bin/masakari-manage
- /usr/bin/masakari-status
- /usr/bin/masakari-wsgi
- No sudo fragments
- No polkit files
- No udev rules
- unit tests / autopkgtests
- autopkgtest is a smoke-test ensures all daemons appear to start
correctly
- unit tests are run during build
- No cron jobs
- Build logs:
- A few unit test failures during the build
- lintian complains about recursive chown in postinst and systemd service
wrapping init script (plus binaries without man-pages and an embedded
copy of jquery/bootstrap etc) but these are not major issues
- No processes spawned
- Memory management is python
- No notable File IO
- Logging is clean
- No environment variable usage (other than in unit tests)
- No use of privileged functions
- No use of cryptography / random number sources etc
- No use of temp files (other than in unit tests)
- Network handling looks pretty safe
- No use of WebKit
- No use of PolicyKit
- No significant static analysis results from coverity / bandit
Other than the chmod/chown typo in the postinst masakari looks pretty good
and maintainable - Security team ACK for promoting masakari to main once
the postinst typo is investigated/fixed.
I reviewed masakari 9.0.0~b2~ git2020020609. 8b122a8- 0ubuntu2 as checked into
focal. This shouldn't be considered a full audit but rather a quick gauge
of maintainability.
masakari is a OpenStack component providing a high availability service for
instances - this allows KVM-based virtual machine instances to be restarted
automatically in the event of failure.
- No CVE History pkg-tools, systemd_ enable, dh_installinit) to setup apache site config etc for masakari/ masakari. sqlite pkg-tools to automatically generate the rest masakari- api masakari- engine masakari- manage masakari- status masakari- wsgi
- No particularly security relevant Build-Depends
- apache2-dev, debhelper, dh-apache2, dh-python, openstack-
python3-all, python3-setuptools, python3-sphinx,
- pre/post inst/rm scripts
- A bunch of automatically added scripts (from dh_apache2, dh_python3,
dh_
the API endpoint, compile python code and setup systemd units /
initscript appropriately
- postinst to add masakari group and user and ensure directories and
databases etc are owned by the masakari user/group
- NOTE: there appears to be a typo in the postinst script which uses
chmod instead of chown:
- chmod masakari:masakari /var/lib/
- ^^^^^ should this be chown instead?
- init scripts
- Simple init script to declare the masakari-engine and then uses
openstack-
- systemd units
- Simple service to call out to the init script to start directly but
managed by systemd as a service
- No dbus services
- No setuid binaries
- python3-masakari provides the following binaries in PATH
- /usr/bin/
- /usr/bin/
- /usr/bin/
- /usr/bin/
- /usr/bin/
- No sudo fragments
- No polkit files
- No udev rules
- unit tests / autopkgtests
- autopkgtest is a smoke-test ensures all daemons appear to start
correctly
- unit tests are run during build
- No cron jobs
- Build logs:
- A few unit test failures during the build
- lintian complains about recursive chown in postinst and systemd service
wrapping init script (plus binaries without man-pages and an embedded
copy of jquery/bootstrap etc) but these are not major issues
- No processes spawned
- Memory management is python
- No notable File IO
- Logging is clean
- No environment variable usage (other than in unit tests)
- No use of privileged functions
- No use of cryptography / random number sources etc
- No use of temp files (other than in unit tests)
- Network handling looks pretty safe
- No use of WebKit
- No use of PolicyKit
- No significant static analysis results from coverity / bandit
Other than the chmod/chown typo in the postinst masakari looks pretty good
and maintainable - Security team ACK for promoting masakari to main once
the postinst typo is investigated/fixed.