[Bug 1815991] Re: [MIR] masakari and masakari-monitors

Alex Murray alex.murray at canonical.com
Tue Feb 25 02:09:05 UTC 2020


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.

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to masakari-monitors in Ubuntu.
https://bugs.launchpad.net/bugs/1815991

Title:
  [MIR] masakari and masakari-monitors

Status in masakari package in Ubuntu:
  New
Status in masakari-monitors package in Ubuntu:
  New

Bug description:
  [Availability]
  Currently in universe.

  [Rationale]
  Masakari is an OpenStack project that we're ready to support in main.

  [Security]
  No security history.

  [Quality Assurance]
  Packages work out of the box with no prompting. There are no major bugs in Ubuntu and there are no major bugs in Debian. Unit tests are run during build.

  [Dependencies]
  All are in main.

  [Standards Compliance]
  FHS and Debian Policy compliant.

  [Maintenance]
  Python packages that the OpenStack Team will take care of.

  [Background]
  Masakari provides Virtual Machine High Availability (VMHA) service for OpenStack clouds by automatically recovering the KVM-based Virtual Machine(VM)s from failure events such as VM process down, provisioning process down, and nova-compute host failure. It also provides API service for manage and control the automated rescue mechanism.

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



More information about the Ubuntu-openstack-bugs mailing list