[MIR] ceph-iscsi, tcmu, python-configshell-fb, python-rtslib-fb, urwid

Bug #1854362 reported by James Page on 2019-11-28
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ceph-iscsi (Ubuntu)
Undecided
Unassigned
python-configshell-fb (Ubuntu)
Undecided
Ubuntu Security Team
python-rtslib-fb (Ubuntu)
Undecided
Mathieu Trudel-Lapierre
tcmu (Ubuntu)
Undecided
Ubuntu Security Team
urwid (Ubuntu)
Undecided
Maria Emilia Torino

Bug Description

== ceph-iscsi ==

[Availability]
In universe

[Rationale]
Provides iSCSI gateway to a Ceph cluster, allowing clients which don't understand RBD to use Ceph storage.

[Security]
No security history found.

[Quality assurance]
Package runs tests during package build (submitted back to Debian).

[Dependencies]
All in main or on this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-openstack

== tcmu ==

[Availability]
In universe

[Rationale]
Dependency for ceph-iscsi

Handles the userspace side of the LIO TCM-User backstore allowing LIO to use librbd for Ceph backed block devices.

[Security]
Some security history:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tcmu

All in older versions.

[Quality assurance]
No tests in source package for execution during package build.

[Dependencies]
All in main or on this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-openstack

== python-configshell-fb ==

[Availability]
In universe

[Rationale]
Dependency for ceph-iscsi

[Security]
No security history

[Quality assurance]
No tests in source package for execution during package build.

[Dependencies]
All in main or on this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-openstack

== python-rtslib-fb ==

[Availability]
In universe

[Rationale]
Dependency for ceph-iscsi

[Security]
No security history

[Quality assurance]
No tests in source package for execution during package build.

[Dependencies]
All in main or on this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-openstack

== urwid ==

[Availability]
In universe

[Rationale]
Dependency for python-configshell-fb

[Security]
No security history

[Quality assurance]
Tests present and executed during package build.

[Dependencies]
All in main or on this MIR

[Standards compliance]
OK

[Maintenance]
ubuntu-openstack

James Page (james-page) on 2019-11-28
summary: - [MIR] ceph-iscsi, tcmu-runner
+ [MIR] ceph-iscsi, tcmu, python-configshell-fb, python-rtslib-fb
James Page (james-page) on 2019-11-28
description: updated
description: updated
description: updated
description: updated
James Page (james-page) on 2019-11-28
summary: - [MIR] ceph-iscsi, tcmu, python-configshell-fb, python-rtslib-fb
+ [MIR] ceph-iscsi, tcmu, python-configshell-fb, python-rtslib-fb, python-
+ urwid
description: updated
description: updated
summary: - [MIR] ceph-iscsi, tcmu, python-configshell-fb, python-rtslib-fb, python-
- urwid
+ [MIR] ceph-iscsi, tcmu, python-configshell-fb, python-rtslib-fb, urwid
James Page (james-page) wrote :

Bug subscriptions added for ubuntu-openstack.

ceph-iscsi will be seeded if MIR is approved.

description: updated
description: updated
Changed in urwid (Ubuntu):
status: New → In Progress
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)

urwid should have security review. Packaging for it looks fine, but it does handle input, present UI that is used in core places for the OS (such as in the installer, even though that's a snap...)

Changed in urwid (Ubuntu):
status: In Progress → New
assignee: Mathieu Trudel-Lapierre (cyphermox) → Ubuntu Security Team (ubuntu-security)
Changed in tcmu (Ubuntu):
status: New → In Progress
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)

tcmu is a high-impact target that will handle storage requests and potentially allow an attacker to intercept data. I'm concerned by the fact the Debian maintainer felt they had to disable -Werror to make things work on 32-bit; even if that's not necessarily out main focus: it points to potential issues in the code, code that is not necessarily very portable or that might be hard to maintain in the future. I'll let the Security Team give their opinion on it and decide.

Changed in tcmu (Ubuntu):
assignee: Mathieu Trudel-Lapierre (cyphermox) → Ubuntu Security Team (ubuntu-security)
status: In Progress → New
Changed in python-rtslib-fb (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ceph-iscsi (Ubuntu):
status: New → Confirmed
Changed in python-configshell-fb (Ubuntu):
status: New → Confirmed
Changed in python-rtslib-fb (Ubuntu):
status: New → Confirmed
Changed in tcmu (Ubuntu):
status: New → Confirmed
Changed in urwid (Ubuntu):
status: New → Confirmed
Changed in python-configshell-fb (Ubuntu):
assignee: nobody → Christian Ehrhardt  (paelzer)

For python-configshell-fb

[Summary]
- Overall looks ok, MIR Team ack
- @Openstack team: it would be great if you'd would fix https://bugs.launchpad.net/ubuntu/+source/python-configshell-fb/+bug/1776761
  If you happen to UCA port this to 18.04 that might help anyway (unless you plan to add that package to UCA itself)
- While attack surface seems minimal the value of getting in seems high in this case, so security should have a look (assigning them)

[Duplication]
There is duplication around this project but not in Main.
https://pypi.org/project/configshell-fb/ belongs to https://github.com/open-iscsi/configshell-fb
Those are all forks and a project has to live in either "all -fb or none" world to work.
But Debian/Ubuntu run the -fb path of this everywhere, so that is good.

[Embedded sources and static linking]
- no embedded sources
- no static linking (python)
- no golang package

[Security]
- no CVE history
- no daemon as root
- no use of webkit1,2
- no use of lib*v8 directly
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

But:
- does parse data formats from caller and coming back from configshell-fb
In general since this deals with setting up storage access to critical data is close.
OTOH attack surface is low as you'd need to have control of the application or the storage already.
Never the less it seems reasonable to ask security to have a look.

[Common blockers]
- builds fine atm
- unfortunately there is no test suite (neither build time nor autopkgtest)
- ubuntu-openstack is already subscribed to bugs of this
- no translations available (none needed for this case)
- dh helpers for python are used
- python2 packages present but not part of the dependency that will pull it into main

[Packaging red flags]
- no Ubuntu delta
- no symbols tracking in python to consider
- watch file is present
- Upstreams releases are not rare, but at what seems random intervals
  - Debian usually packages those quite well being up to date or one behind
  - E.g. the current release isn't packaged but the delta 1.1.25 -> 1.1.27 seems negligible so that is overall ok
- not causing problems for MOTUs
- no massive Lintian warnings
- d/rules is very small and clear
- no Built-Using
- no go package for further considerations

[Upstream red flags]
- no critical Errors/warnings during the build
- no Incautious use of malloc/sprintf (python)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no User nobody
- no use of setuid
- No important bugs (crashers, etc) in Debian or Ubuntu going forward
  - https://bugs.launchpad.net/ubuntu/+source/python-configshell-fb/+bug/1776761 ould be nice to be SRUed I guess
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI

Changed in python-configshell-fb (Ubuntu):
assignee: Christian Ehrhardt  (paelzer) → Ubuntu Security Team (ubuntu-security)
James Page (james-page) wrote :

@cyphermox (and security team)

Reading the code this is typical mis-use in mixing uint64_t and size_t on the assumption that size_t is 64 bit - so code compiles fine on 64bit but fails on 32bit.

I've fixed numerous issues of this type in other code bases so I'll take a look - the return type of tcmu_lba_to_byte is uint64_t which is the correct approach - size_t usage needs to be switch to match.

Changed in urwid (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → Maria Emilia Torino (emitorino)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers