I reviewed masakari-monitors 9.0.0~b1~git2019121714.b717be1-0ubuntu1 as
checked into focal. This shouldn't be considered a full audit but rather a
quick gauge of maintainability.
masakari-monitors provides various binary packages containing separate
monitor instances for masakari-engine - these allow to monitor hosts /
processes etc and integrate with the masakari API to provide high
availability of instances in OpenStack.
- No CVE History
- No security relevant Build-Depends
- pre/post inst/rm scripts
- Like other openstack packages, various auto-generated versions - these
all look fine
- masakari-monitors-common provides postinst to create the
masakarimonitors group and user and chown/chmod various
files/directories as appropriate
- There doesn't appear to be an equivalent prerm - should there be?
- init scripts
- Like masakari, uses the openstack packaging helpers to auto-generate
init scripts for each monitor daemon - these look fine
- systemd units
- Like masakari, these wrap the init scripts generated above
- No dbus services
- No setuid binaries
- python3-masakari-monitors provides the following binaries in PATH (one
for each monitor):
- /usr/bin/masakari-hostmonitor
- /usr/bin/masakari-instancemonitor
- /usr/bin/masakari-introspectiveinstancemonitor
- /usr/bin/masakari-processmonitor
- sudo fragment in maskari-monitors-common to allow the masakarimonitors
user to execute as root the privsep-helper binary (provided by oslo) as
needed
- No polkit files
- No udev rules
- unit tests / autopkgtests
- Like masakari, simple smoketest as autopkgtest to ensure daemons start
/ run
- unit tests run during build
- No cron jobs
- Build logs are pretty clean
- Like masakari lintian complains of systemd unit wrapping init script
and too other minor issues
- Processes spawned
- The process monitor uses ps to monitor for processes - this
looks safe and doesn't appear to allow command-injection
- Memory management is python
- File IO
- The process monitor loads YAML directly from
/etc/masakarimonitors/process_list.yaml which is owned by root, group
masakarimonitors so this should be fine as this is trusted
- Logging looks clean
- No obvious environment variable usage
- No obvious use of privileged functions
- No use of cryptography / random number sources etc
- No use of temp files
- No obvious direct use of networking
- No use of WebKit
- No use of PolicyKit
- Instead uses oslo for privilege separation
- No significant static analysis (coverity/bandit)
Security team ACK for promoting masakari-monitors to main.
I reviewed masakari-monitors 9.0.0~b1~ git2019121714. b717be1- 0ubuntu1 as
checked into focal. This shouldn't be considered a full audit but rather a
quick gauge of maintainability.
masakari-monitors provides various binary packages containing separate
monitor instances for masakari-engine - these allow to monitor hosts /
processes etc and integrate with the masakari API to provide high
availability of instances in OpenStack.
- No CVE History monitors- common provides postinst to create the itors group and user and chown/chmod various directories as appropriate masakari- monitors provides the following binaries in PATH (one masakari- hostmonitor masakari- instancemonitor masakari- introspectivein stancemonitor masakari- processmonitor monitors- common to allow the masakarimonitors
- No security relevant Build-Depends
- pre/post inst/rm scripts
- Like other openstack packages, various auto-generated versions - these
all look fine
- masakari-
masakarimon
files/
- There doesn't appear to be an equivalent prerm - should there be?
- init scripts
- Like masakari, uses the openstack packaging helpers to auto-generate
init scripts for each monitor daemon - these look fine
- systemd units
- Like masakari, these wrap the init scripts generated above
- No dbus services
- No setuid binaries
- python3-
for each monitor):
- /usr/bin/
- /usr/bin/
- /usr/bin/
- /usr/bin/
- sudo fragment in maskari-
user to execute as root the privsep-helper binary (provided by oslo) as
needed
- No polkit files
- No udev rules
- unit tests / autopkgtests
- Like masakari, simple smoketest as autopkgtest to ensure daemons start
/ run
- unit tests run during build
- No cron jobs
- Build logs are pretty clean
- Like masakari lintian complains of systemd unit wrapping init script
and too other minor issues
- Processes spawned masakarimonitor s/process_ list.yaml which is owned by root, group itors so this should be fine as this is trusted
- The process monitor uses ps to monitor for processes - this
looks safe and doesn't appear to allow command-injection
- Memory management is python
- File IO
- The process monitor loads YAML directly from
/etc/
masakarimon
- Logging looks clean
- No obvious environment variable usage
- No obvious use of privileged functions
- No use of cryptography / random number sources etc
- No use of temp files
- No obvious direct use of networking
- No use of WebKit
- No use of PolicyKit
- Instead uses oslo for privilege separation
- No significant static analysis (coverity/bandit)
Security team ACK for promoting masakari-monitors to main.