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

Bug subscriptions added for ubuntu-openstack.

ceph-iscsi will be seeded if MIR is approved.

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...)

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.

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

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

@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.

Any chances of this landing in 20.04 ?

I really would like to have:

- python3-configshell-fb
- python3-rtslib-fb
- targetcli-fb

included in 20.04 [main] as the official - including the kernel side - way to provide iSCSI targets (https://www.kernel.org/doc/Documentation/target/tcmu-design.txt) to other hosts. Specially if we consider HA related software: this is the only iSCSI target project that fully supports SCSI 3 reservations (tgt does not: https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/1863688).

How can I help moving this further ?

Thank you!

Rafael

targetcli-fb has not been mentioned previously and is not a task on this bug - does it need to be added?

targetcli-fb depends on python3-rtslib-fb and project is hosted here:

https://github.com/open-iscsi/targetcli-fb

It is not a direct need judging original request by James Page BUT its the CLI for configuring LIO/TCM kernel function. There is no other tool able to configure LIO/TCM kernel iSCSI target.

BTW, if this sounds good, and I hope it does, I'd vote for demoting tgt in favor of having targetcli-fb as the only iSCSI target available in [main] (good comparison tables can be found at: http://www.linux-iscsi.org/wiki/Features, and justifies the request IMO).

+1 on the switch from TGT to LIO however -server guide will probably need updates to support this.

(and lets do that sooner rather than later in the cycle if the general consensus is that's a good idea)

cinder-volume will need an update to switch to LIO instead of tgt if we make this switch.

James,

Its in my TODO list to take care of iSCSI session in server guide after freeze. So, yep. If you have someone to take care of cinder at your side than I think we're good.

Adding targetcli-fb to the MIR list then...

I reviewed python-configshell-fb 1.1.fb25-1.1 as checked into focal. This
shouldn't be considered a full audit but rather a quick gauge of
maintainability.

python-configshell-fb provides a python library which is used for building
CLI based user-interfaces. Upstream appears healthy and responsive.

- CVE History:
  - None
- No security relevant Build-Depends
  - debhelper, dh-python, python3-all, python3-pyparsing, python3-setuptools, python3-six
- pre/post inst/rm scripts
  - These are fine - just the auto-generated ones by dh_python3 to
    py3compile on postinst and py3clean on prerm
- No init scripts
- No systemd units
- No dbus services
- No setuid binaries
- No binaries in PATH
- No sudo fragments
- No polkit files
- No udev rules
- No unit tests / autopkgtests
  - This will make doing any security updates hard to test...
- No cron jobs
- Clean build log

- No processes spawned
- File IO
  - Uses files for preferences and logging but these are all parameters to
    the library and not hard-coded
  - Preferences are saved and restored using pickle which could present a
    security issue since this does little sanity checking on formats etc -
    however this is done using a file-name provided by the user of the
    library and relative to the user's home directory so this is likely
    safe - although there is no use of umask() to ensure this file is not
    accessible by others so perhaps that at least should be employed
- Logging
  - Uses general python format strings etc - this is safe
- No environment variable usage
- No Use of privileged functions
- No Use of cryptography / random number sources etc
- No Use of temp files
- No Use of networking
- No Use of WebKit
- No Use of PolicyKit

Static analysis via bandit and Coverity does not show anything significant

Security team ACK for promoting python-configshell-fb to main however I
would be happier if some unit tests were added so that some testing can be
done for any future updates to ensure regressions are not introduced.

Thanks a lot Alex. I'll add some DEP8 tests to python-configshell-fb. Already created a card for it.

##
## SUMMARY (please correct me if I'm wrong)
##

python-rtslib-fb - lib: object API for managing Linux LIO kernel target
python-configshell-fb - lib: framework for building CLI-based apps

MIR #1)

ceph-iscsi - LIO gateways for Ceph (logic and CLI tools)

deps:
  python3-configshell-fb - (see below in this summary)
  python3-rtslib-fb - (see below in this summary)
  python3-urwid - lib: curses-based UI lib for python (cli)
  tcmu - userland portion of Linux LIO (ceph, qcow2)

MIR #2)

targetcli-fb - Linux LIO kernel target command line interface

deps:
  python3-configshell-fb - (see below in this summary)
  python3-rtslib-fb - (see below in this summary)

----

## DONE

- urwid should have security review
  - emitorino gets to itself urwid review (2020-01-08)

- tcmu is high-impact target (because of Werror disablement)
  - comments from jamespage about portability (cyphermox concerns on Werror)

- python3-configshell-fb was reviewed by paelzer (2019-12-05) MIR
- python3-configshell-fb was reviewed by alexmurray (2020-02-21) SECURITY

----

Note: The next 3 items are orthogonal:

## MISSING (for both MIRs to happen at same time):

- python3-rtslib-fb needs MIR and SECURITY review
- python3-urwid needs MIR and SECURITY review (emitorino to finish ?)
- tcmu needs MIR and SECURITY review
- ceph-iscsi needs MIR and SECURITY review
- targetcli-fb needs MIR and SECURITY review

## MISSING (for ceph-iscsi MIR to happen):

- python3-rtslib-fb needs MIR and SECURITY review
- python3-urwid needs MIR and SECURITY review (emitorino to finish ?)
- tcmu needs MIR and SECURITY review
- ceph-iscsi needs MIR and SECURITY review

## MISSING (for targetcli-fb MIR to happen):

- python3-rtslib-fb needs MIR and SECURITY review
- targetcli-fb needs MIR and SECURITY review

----------------------------

Request: If there is no urgent need for ceph-iscsi to be LIO based on 20.04, would it be possible to prioritize the last MISSING item described above ? This way I would be able to have targetcli-fb in 20.04 and have an interface for LIO.

Observation: Let me know if there is anything on my side I can do to help in accelerating either ceph-iscsi and/or targetcli-fb MIRs.

Thanks a lot!

- rafaeldtinoco

@rafaelftinoco - as the security team, we don't necessarily do a security review for all MIRs - only those which are deemed security relevant - and so we normally wait for the MIR team to do their review first and then if they request a security review, then we add it to our queue. So for now we only have urwid and tcmu on our queue. Please let us know if there is anything else you want us to prioritise.

Thanks for the summary, lets tackle the remaining tasks.
I still doubt we can make it for 20.04, but lets see how things go and decide to punt to 20.10 when we really missed it.

Targets:
- I: ceph-iscsi
- II: targetcli-fb

(smaller) Summary for the current state (I updated bug tasks accordingly)
I: ceph-iscsi - MIR tbd
I/II: python-configshell-fb - MIR ack, Security ack
I/II: python-rtslib-fb - MIR tbd
II: targetcli-fb - MIR tbd
I: tcmu - MIR ack, Security in-queue (undefined)
I: urwid - MIR ack, Security in-queue (emitorino)

@Rafael/@James - if you could take a look at the "tcmu 32 bit Werror" issues, that would be great.

[Summary]
MIR Team conditional-Ack. Good packaging in general, but we need the steps below to be completed before being really ready for promotion:

@rafaeldtinoco - please update targetcli-fb
 - update targetcli-fb to 2.1.51
 - fix d/watch to detect the non *fb* versions
 - as usual work with Debian to have it there as well sooner or later
 - not sure but it might even need an epoch :-/
   $ dpkg --compare-versions 2.1.fb49 lt-nl 2.1.51 => NO
   But OTOH:
   UserWarning: The version specified ('2.1.fb49') is an invalid version
@rafaeldtinoco - please get Josh to subscribe to (all) these packages
 - we can drop that later, but that way we
   a) don't miss it later
   b) get a glimpse of the bug influx on these packages
@rafaeldtinoco - tests missing
Can we get some tests that will exercise targetcli-fb in this or another
package of this MIRs context?
@Rafael - once you are done with the above, please assign security to the targetcli-fb task

@security - please put it on your review queue, but only process it once we are
at version >=2.1.51 which @rafaeldtinoco will work on first.

[Duplication]
This is "Command shell for managing the Linux LIO kernel target" we don't have that in main yet.
TGT is no full alternative and to be replaced (tgt to be demoted) once we are ready to promote this.

[Dependencies]
OK:
- python3-rtslib-fb and python3-configshell-fb which are part of this MIR bug as well.
- The rest is in main already.
- No -dev/-debug/-doc packages with extra deps that would be auto-incldued that need exclusion later on promotion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- 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)
=> "viewing, editing, and saving the configuration of the kernel's target
   subsystem" does not have exploitable elements on their own.
   The security in this particular case is needed and done on the kernel side.
   I think as-is no security review would be needed.
   But going to 2.1.51 (see below) will introduce targetclid which then is:

Problem:
- does run a daemon as root
- does parse data formats

I don't think any of that will be critical as it is just parts of the former CLI
portion broken out to a daemon, but e.g. exploiting the daemon could get control
of LIO controlled credentials.
Therefore looking at what we will eventually have a security review (probably
quick) is requested.

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (admin only)?
- no new python2 dependency
- uses dh_python

Problems:
- no Team subscriber yet, server-team please subscribe
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
  -> could we get some basic tests when working on 2.1.51 to at least cover
     and detect the most obv...

^^ The above was for targetcli-fb ^^

## python3-rtslib-fb ##

[Summary]
MIR Team conditional-Ack. Good packaging in general, but we need the steps
below to be completed before being really ready for promotion:
(Note: this is Very similar to targetcli-fb)

@rafaeldtinoco - please update python-rtslib-fb
 - update targetcli-fb to 2.1.71
 - fix d/watch to detect the non *fb* versions
 - as usual work with Debian to have it there as well sooner or later
 - not sure but it might even need an epoch :-/

@rafaeldtinoco - please make install-fail graceful (see below for detail)
Could be just a condition in the service, but that is up to you

@rafaeldtinoco - please get Josh to subscribe to (all) these packages
 - we can drop that later, but that way we
   a) don't miss it later
   b) get a glimpse of the bug influx on these packages

@rafaeldtinoco - tests missing
Can we get some tests that will exercise targetcli-fb in this or another
package of this MIRs context?

@rafaeldtinoco - (optional) targetctl man page
If it seems easy to do writign and proposing upstream a man page would be great,
currently there is nothing but the -h output and that is rather scarce.

@Rafael - once you are done with the above, please assign security to the
python-rtslib-fb task

@security - please put it on your review queue, but only process it once we are
at version >=2.1.71 which @rafaeldtinoco will work on first.

[Duplication]
This is "object API for managing the Linux LIO kernel target"" we don't have
that in main yet. TGT is no full alternative and to be replaced (tgt to be
demoted) once we are ready to promote this.

[Dependencies]
OK:
- All dependencies are in main already.
- No -dev/-debug/-doc packages with extra deps that would be auto-incldued that
  need exclusion later on promotion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not use webkit1,2
- does not use 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)

Problem:
- does run a daemon as root
- does parse data formats

I don't think any of that will be critical it just reads the stored config from
disk and restores it on boot. But one could e.g. mess with the config files to
break it in unexpected ways. The executed program targetctl is part of this
package, so it isn't reviewed already in another context.
=> security review is requested

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (admin only)?
- no new python2 dependency
- uses dh_python

Problems:
- no Team subscriber yet, server-team please subscribe
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
  -> could we get some basic tests when working on 2.1.71 to at least cover
     and detect the most obvious issues)
     It might be ok to get the tests done in one of the packages here that
     would then use all the packages belonging to this "context".
- doesn't install-fa...

## ceph-iscsi ##

[Summary]
MIR Team conditional ack. To be complete I'd recommend an update to v3.4 and I'd
request a security review. The updates are important, but no blocker for the
security review therefore I'm assigning the security Team.

TODOs:
@Jamespage - bug subscriber
I guess openstack will subscribe for this one right?
Jamespage could you make that happen?

@Jamespage - update to version 3.4 for a bunch of crash fixes

@security - please put this on your review queue.

[Duplication]
This is essentially a ceph/LIO gateway translating between the two.
Such functionality isn't in main, duplication is no issue.

[Dependencies]
- no other Dependencies to MIR due to this (only those listed in this bug
  already)
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not use webkit1,2
- does not process arbitrary web content
- does not use lib*v8 directly
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- does run two daemons as root
- does parse data formats (via REST API)
- does open a port (for REST)

=> a security review is needed

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error (Thanks James for enabling
    these).
- no translation present, but none needed for this case (admin only)?
- no new python2 dependency
- uses dh_python

Problems:
- Does not yet have a team bug subscriber?
- does not have a test suite that runs as autopkgtest (sort of ok for now, if
  tested e.g. in other openstack context)

[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is ok
- Debian/Ubuntu update history is not long enough to have a good insight how frequent they will be
- promoting this does not seem to cause issues for MOTUs that so far maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- not using Built-Using

Problems:
- the current release is not packaged
  => https://github.com/ceph/ceph-iscsi/releases/tag/3.4
  Fixing some crashes
  => https://github.com/ceph/ceph-iscsi/compare/3.3...3.4
  @Jamespage would you mind getting this packaged?

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (python)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid (needs very careful design (prefer systemd to set those for services))
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks

Problems:
- The upstream bug tracker has a list of bad bugs, but they seem to be actively
  worked on so that should be ok.

Updating my small summary of this morning after the MIR reviews.
I still doubt (even more now) we can make it for 20.04, but lets see how things go and decide to punt to 20.10 when we really missed it.

Targets:
- I: ceph-iscsi
- II: targetcli-fb

Current state:
I: ceph-iscsi - MIR ack, Update to 3.4 recommended, Security review needed
I/II: python-configshell-fb - MIR ack, Security ack - READY
I/II: python-rtslib-fb - MIR ack, Updates and fixes needed (@Rafael), then afterward security review needed
II: targetcli-fb - MIR conditional-ack, Updates and fixes needed (@Rafael), then afterward security review needed
I: tcmu - MIR ack, Security in-queue (undefined)
I: urwid - MIR ack, Security in-queue (emitorino)

TODOs:
- @Rafael/@James: if you could take a look at the "tcmu 32 bit Werror" issues, that would be great.
- @Rafael: please work on todos listed in comment #24 comment #26 and assign these tasks to security after they are done
- @James: please work on todos listed in comment #27
- @Security - as usual please let us know via an update here once these entered your review queue and once people are assigned.

Re "tcmu 32 bit Werror" - I supplied a patch for the actual error raised on 32 bit archs but the Debian maintainer rejected my change to not disable that compiler feature (-Werror)

ceph-iscsi:

ubuntu-openstack added as bug subscriber.

package updated to 3.4 as requested (thanks for spotting that).

Seeing:
 ceph-iscsi | 3.4-0ubuntu1 | focal/universe | source, all
thanks James!

You also said
[12:22] <jamespage> cpaelzer, rafaeldtinoco: rtslib and configshell are straight updates - have those ready for upload
=> That sounds great. I'd almost encourage you to upload it right away. To later catch up I'd ask to open debian MPs as well.

=> That leaves the update of targetcli-fb which at least has this new targetclid daemon that might need to be packaged and tested to work well.

I also uploaded the requested versions of configshell-fb and rtslib-fb to get things up-to-date for the release feature freeze.

I reviewed urwid 2.0.1-2build3 as checked into focal. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

urwid is a console-based display and user interface framework/library for python 2.7 and 3.4+

- CVE History:
  - none found
- Build-Depends?
  - nothing troubling found
- pre/post inst/rm scripts?
  - n/a
- init scripts?
  - n/a
- systemd units?
  - n/a
- dbus services?
  - n/a
- setuid binaries?
  - n/a
- binaries in PATH?
  - n/a
- sudo fragments?
  - n/a
- udev rules?
  - n/a
- unit tests / autopkgtests?
  - there are some tests but no autopackage tests. The tests run fine when I
    manually run them but I don't see them running during the build.
- cron jobs?
  - n/a
- Build logs:
  - lintian warns about old python versions

- Processes spawned?
  - the default for Terminal is using the value of SHELL env var as the command
  - it execs a command for it virtual terminal class and some for mouse pointer integration
  - it also execs some python for reraising exceptions
- Memory management?
  - n/a
- File IO?
  - paths appear to be constructed safely
  - it's not really getting input from files
  - umask is set to 0 when deamonizing
  - umask not explicitly set for file creation
- Logging?
  - looking isn't used much and looks ok
- Environment variable usage?
  - env is not sanitized
  - this could possibly be misused or produce unanticipated results but that isn't happening as used by python-configshell-fb
- Use of privileged functions?
- Use of cryptography / random number sources etc?
  - n/a
- Use of temp files?
  - pipes located in /tmp by default, this isn't being used for our purposed right now.
- Use of networking?
  - I didn't focus on this very much becuause urwid as used by python-configshell-fb doesn't use networking
  - input is parsed one character at a time.
- Use of WebKit?
- Use of PolicyKit?
  - n/a

- Any significant cppcheck results?
  - No
- Any significant Coverity results?
  - No

Bandit flagged creation of pipes in /tmp in web_display.py as potentially unsafe. That functionality of the framework is not being used
by python-configshell-fb but it could probably be improved.

Security team ACK. My recommendation is that the web_display tmp files be cleaned up to use python's tempfile but I don't think it needs to block inclusion into main at this time because it isn't being used.

Rafael was working on updating targetcli and I was reviewing/helping with that.

TODOs:
@Rafael
- install state of rtslib-fb-targetctl.service still is bad in containers
  Unless you find any idea why this would ever make sense in a container (I don't)
  you can start by adding
    ConditionVirtualization=!container
  and upload that to python3-rtslib-fb
- probably targetclid might need the same treatment as it most likely will fail the same way
- fixup targetcli service
  /lib/systemd/system/targetclid.socket:6: ListenStream= references a path below legacy directory /var/run/, updating /var/run/targetclid.sock
- some things are still missing on the sockets/service activation sequence
  The socket fails via targetclid.socket: Socket service targetclid.service already active, refusing.

Updating my small summary of this morning after the MIR reviews.

Targets:
- I: ceph-iscsi
- II: targetcli-fb

Current state:
I: ceph-iscsi - MIR ack, Security in-queue
I/II: python-configshell-fb - MIR ack, Security ack - READY
I/II: python-rtslib-fb - MIR ack, fixes needed (@Rafael), then security review
II: targetcli-fb - MIR conditional-ack, Updates and fixes needed (@Rafael), then security review
I: tcmu - MIR ack, Security in-queue (undefined)
I: urwid - MIR ack, Security ack - READY

I split the service change for rtslib-fb into https://bugs.launchpad.net/rtslib-fb/+bug/1865037 as the MIR and security review isn't dependent on it.

Updating my small summary of this morning after the MIR reviews.

Targets:
- I: ceph-iscsi
- II: targetcli-fb

Current state:
I: ceph-iscsi - MIR ack, Security in-queue
I/II: python-configshell-fb - MIR ack, Security ack - READY
I/II: python-rtslib-fb - MIR ack, needs Security review (not yet queued)
II: targetcli-fb - MIR conditional-ack, Updates and fixes needed (@Rafael), then security review
I: tcmu - MIR ack, Security in-queue (undefined)
I: urwid - MIR ack, Security ack - READY

@Rafael
- I fixed the todos on targetcli and am pushing to the branch that I linked in your MP
- I've broken the rtslib-fb-targetctl into an extra bug

=> once you have re-reviewed targetcli and uploaded it we can set that to security as well.

Ok, Im uploading targetcli-fb based on our discussions after you fixed the todos:

https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/targetcli-fb/+git/targetcli-fb/+merge/379938

And will assign security team to targetcli-fb after uploaded.

Thanks a lot @Christian.

Targetcli got into -proposed:

https://bugs.launchpad.net/ubuntu/+source/targetcli-fb/1:2.1.51-0ubuntu1

Subscribing security for targetcli-fb MIR security analysis.

@Christian: for the record, Chris Coulson is looking at tcmu.

I reviewed targetcli-fb 1:2.1.51-0ubuntu1 as checked into focal. This
shouldn't be considered a full audit but rather a quick gauge of
maintainability.

targetcli-fb is a python package for configuring and managing the LIO
(Linux IO) generic SCSI target.

- CVE History:
  - None
- Build-Depends
  - No security sensitive build-depends:
    - debhelper, dh-python, python3-all, python3-configshell-fb,
      python3-gi, python3-rtslib-fb, python3-setuptools, python3-six
- pre/post inst/rm scripts
  - only auto-generated ones from dh_python3/dh_installsystemd
- No init scripts
- 1 systemd unit for the targetclid daemon
- No dbus services
- No setuid binaries
- binaries in PATH
  - /usr/bin/targetcli
  - /usr/bin/targetclid
- No sudo fragments
- No polkit files
- No udev rules
- No autopkgtests or unit tests
  - This makes it very difficult for the security team to ensure any
    possible security updates do not introduce regressions
- No cron jobs
- Build logs:
  - No significant errors / warnings

- No processes spawned
- Memory management is python
- File IO
  - /var/run/targetclid.sock is world-writable (0o666) so anyone can
    connect to it and there is no authentication done on the user who is
    interacting with targetclid via this socket - as such an unprivileged
    user can connect to it and send commands to targetclid which will
    execute them with no privilege checks. This is likely a security
    vulnerability. The permissions on this socket path should be explicitly
    set so that this is only writable by owner/group and not others,
    ie. 660 rather than the current 666. Since this is generally created by
    systemd, adding SocketMode=0660 to the targetclid.socket systemd unit
    should be sufficient. This has been reported upstream at
    https://github.com/open-iscsi/targetcli-fb/issues/162
  - targetclid uses the hardcoded file-path /tmp/data.txt for handling
    interaction with clients - this is a potential security vulnerability
    since if a client creates a symlink at /tmp/data.txt to some root owned
    file, targetclid would write it's own data to that target file - I
    notice this has already been fixed upstream via
    https://github.com/open-iscsi/targetcli-fb/pull/156 /
    https://github.com/open-iscsi/targetcli-fb/commit/23877ab4afbf0c2fe4092936261d92d7b7fbff11
    and so this should be patched to avoid any possible security issue as a
    result
  - Also uses hard-coded path to /var/run/targetclid.pid
  - Uses the config file ~/.targetcli
  - saveconfig commands allows to specify any resulting filename so can be
    used to overwrite arbitrary files on the system - as such there should
    probably be stricter checks on the target filename OR that targetcli
    can only ever be run as a regular user (the current location of the )
  - restoreconfig command will read from any specified config file without
    checking ownership etc so again any client to targetclid should be
    considered trusted
- Logging
  - Is via ConfigShell (from python-configshell-fb) and looks fine
- Environment variable usage
  - targetclid uses TARGETCLI_HOME to override path of ~/.targetcli and
    LISTEN_PID to support systemd-b...

I reviewed tcmu 1.5.2-5build1 as checked into focal. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

tcmu is the userspace side of the kernel's LIO TCM in userspace backstore,
which allows backstores for LIO (the kernel's SCSI target) to live outside
of the kernel and to be implemented in userspace. It consists of a daemon
(tcmu-runner) which communicates with the kernel side via the TCM-USER
generic netlink family. Handlers for SCSI commands are implemented as modules
that run inside tcmu-runner - currently built and insalled are "File-backed
optical", "ZBC emulation", "QCOW image file" and "Ceph RBD" handlers. Handlers
process SCSI commands from a ring buffer shared between the kernel and
userspace.

- Some limited CVE history - a mixture of DoS and information leaks, all fixed
  in the current version:
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000198
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000199
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000200
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000201
- Upstream is active, and we had a positive interaction with them whilst I was
  working on this MIR (see https://github.com/open-iscsi/tcmu-runner/issues/613).
- Build-depends all in main (cmake, kmod, glib2.0, libnl3, ceph, pkg-config,
  zlib)
  - It build-depends on libkmod-dev because it consumes symbols from libkmod2,
    but what does it need the kmod binaries for at build time?
- tcmu-runner has postinst/prerm/postrm scripts just containing autogenerated
  snippets from dh_installinit and dh_installsystemd.
  - It appears to be missing cleanup hooks for /etc/tcmu/tcmu.conf though.
- Contains an init script and systemd unit that starts the tcmu-runner daemon,
  which is started by default as part of the multi-user target.
  - The daemon runs as root.
  - Doesn't listen on any ports.
- Also installs a dbus service to activate the tcmu-runner daemon.
- It exposes a couple of dbus interfaces:
  - org.kernel.TCMUService1 which provides a single CheckConfig method and is
    exported for each registered type (with a type specific object path). None
    of the internal plugins appear to implement check_config, so I'd imagine it
    just always returns success for these.
  - org.kernel.TCMUService1.HandlerManager1 which allows external handlers for
    a type to be registered (via the RegisterHandler method). Calls to
    org.kernel.TCMUService1.CheckConfig are then proxied to the external handler
    process, which owns a type-specific well-known name on the system bus.
  - The dbus policy allows all users to call
    org.kernel.TCMUService1.HandlerManager1.RegisterHandler, which doesn't seem
    desirable. I don't think there is a direct security impact from this, as
    external handlers need to be privileged in order to own the type-specific
    well-known name on the system bus, and the call will return an error if
    called before that name is owned. But I think this should only be callable
    as the root user.
- No setuid binaries.
- One binary in PATH (/usr/bin/tcmu-runner).
- No sudo fragments.
- No polkit files.
- No udev r...

See https://github.com/open-iscsi/tcmu-runner/issues/582 for the dbus-policy-without-send-destination lintian warning.

Upstream have merged in a fix for the world-writable targetcli-fb daemon socket - https://github.com/open-iscsi/targetcli-fb/issues/162 - and assigned CVE-2020-10699 for it - but there has been no official release. With this fix in place, I would be happy to change the NACK to an ACK for targetcli-fb.

I'm starting to look at python-rstlib-fb and lintian (from bionic) reported:

Output of lintian:
 W: python-rtslib-fb source: debhelper-compat-file-is-missing
 W: python-rtslib-fb source: package-uses-deprecated-debhelper-compat-version 1
 E: python-rtslib-fb source: package-uses-debhelper-but-lacks-build-depends
 E: python-rtslib-fb source: missing-build-dependency debhelper

Thanks

Funny, our tooling also collected these lintian messages, in a different spot:

python3-rtslib-fb_2.1.71-0ubuntu1_all.deb:
W: python3-rtslib-fb: binary-without-manpage usr/bin/targetctl
W: python3-rtslib-fb: maintainer-script-should-not-use-update-alternatives-remove postrm:6

Thanks

On 02/04/2020 01:04, Alex Murray wrote:
> Upstream have merged in a fix for the world-writable targetcli-fb daemon
> socket - https://github.com/open-iscsi/targetcli-fb/issues/162 - and
> assigned CVE-2020-10699 for it - but there has been no official release.
> With this fix in place, I would be happy to change the NACK to an ACK
> for targetcli-fb.
>
> ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-10699

Alex, I left the targetcli-fb MIR attempt to be handled at 20.10. I'll
continue this shortly and will handle this. Thanks for the highlight.

Lintian pointed out a mistake in the python-rtslib-fb packaging:

W: python3-rtslib-fb: binary-without-manpage usr/bin/targetctl
W: python3-rtslib-fb: maintainer-script-should-not-use-update-alternatives-remove postrm:6

 W: python-rtslib-fb source: debhelper-compat-file-is-missing
 W: python-rtslib-fb source: package-uses-deprecated-debhelper-compat-version 1
 E: python-rtslib-fb source: package-uses-debhelper-but-lacks-build-depends
 E: python-rtslib-fb source: missing-build-dependency debhelper

(As is usual, I'm not entirely sure why the tooling spits out two different sets of issues; some may be related to a lintian from focal rather than devel.)

Thanks

I reviewed python-rtslib-fb 2.1.71-0ubuntu1 as checked into focal. This
shouldn't be considered a full audit but rather a quick gauge of
maintainability.

python-rtslib-fb is a programmatic interface to the Linux kernel's LIO
target. Working with Python objects causes writes to the kernel's
/sys/kernel/config/target interface.

It also provides an executable to save the live config to a file on
service shutdown, and load the config into the running kernel on service
start.

- No CVEs in our database; when I reported a low severity problem, a fix
  was committed 13 hours later.
- Build-Depends?
  - debhelper-compat (= 9),, dh-python, openstack-pkg-tools (>= 99~),
    python3-all, python3-setuptools, python3-six
- pre/post inst/rm scripts?
  - postrm script improperly removes the alternatives entry against
    policy -- it should be called from prerm instead:
    https://lintian.debian.org/tags/maintainer-script-should-not-use-update-alternatives-remove.html
  - py3compile command isn't guarded with || true; -- is this correct?
- init scripts?
  - initscript has multiple shellcheck warnings
  - race condition combined with busy-wait "sleep"
- systemd units?
  - Creates directory with ExecStart=mkdir -p rather than
    ConfigurationDirectory= directive
- No dbus config
- No setuid executables
- new binary targetctl in PATH
- No sudo fragments
- No polkit rules
- No udev rules
- Very small number of tests -- as doctests -- and I can't tell if they
  run during the build or not
- No cron jobs
- Lintian warnings and errors reported

- Spawns a subprocess to perform module loading -- the subprocess itself
  looks fine, but the module loading feels out of place. There is probably
  a better way to do this.
- File IO is used extensively; some small helper functions are written to
  make it look easy. The tool works extensively in a virtual filesystem
  meant to configure things.
- Very little logging
- No environment variable use
- While this performs privileged operations, it mostly does so via read
  and write -- and the "modprobe" Popen.
- No cryptography
- No temp files
- No networking
- No webkit
- No policykit

While reading the code I found a low-severity issue and reported it:
https://github.com/open-iscsi/rtslib-fb/issues/161
Upstream checked in a fix in 13 hours.

The systemd unit file uses an explicit mkdir call rather than using a
declarative setting.

The postrm/prerm scripts needs work.

Security team ACK for promoting python-rtslib-fb to main. I'd like the
security fix and the packaging issues fixed before this package is
promoted.

Thanks

I've asked Rafael to look after the TODOs that were identified for python-rtslib-fb.
Assigning the task.

Okay, I'm back to this now.

Targets:

- I: ceph-iscsi

- II: targetcli-fb

Summary for the current state:

I: ceph-iscsi
    [-] MIR ack (if everything else is)

I/II: python-configshell-fb
    [.] MIR ack
    [+] Security ack - needs DEP8 inclusion

I/II: python-rtslib-fb
    [+] MIR ack - needs packaging/lintian fixes
    [.] Security ack - upstream fix done

II: targetcli-fb
    [+] MIR ack - needs DEP8 and services/sockets fix
    [.] Security nack->ack - 2 upstream fixes done

I: tcmu
    [.] MIR ack
    [+] Security ack - but needs dbus fix

I: urwid
    [.] MIR ack
    [.] Security: ack

I'm working on the [+] ones.

For targetcli-fb:

https://salsa.debian.org/linux-blocks-team/targetcli-fb/-/merge_requests/8

I'm now waiting Ritesh to accept my merge request updating it to 2.1.53 and fixing the binary package (including documentation, new systemd units, etc).

● targetclid.service - Targetcli daemon
     Loaded: loaded (/etc/systemd/system/targetclid.service; disabled; vendor preset: enabled)
     Active: active (running) since Wed 2020-06-24 20:28:02 UTC; 957ms ago
TriggeredBy: ● targetclid.socket
       Docs: man:targetclid(8)
   Main PID: 22495 (targetclid)
      Tasks: 3 (limit: 23180)
     Memory: 14.7M
     CGroup: /system.slice/targetclid.service
             └─22495 /usr/bin/python3 /usr/bin/targetclid

Jun 24 20:28:02 debian systemd[1]: Started Targetcli daemon.

Service works but I have disabled it by default. Package is good to be merged in Debian.

CURRENT STATUS

Targets:

- I: ceph-iscsi

- II: targetcli-fb

Summary for the current state:

I: ceph-iscsi
    [-] MIR ack (if everything else is)

I/II: python-configshell-fb
    [.] MIR ack
    [.] Security ack - needs DEP8 inclusion

    Suggesting:
    - https://salsa.debian.org/linux-blocks-team/python-configshell-fb/-/merge_requests/3/

II: targetcli-fb
    [.] MIR ack - needs DEP8 and services/sockets fix
    [.] Security nack->ack - 2 upstream fixes done

    Suggesting:
    - https://salsa.debian.org/linux-blocks-team/targetcli-fb/-/merge_requests/8

I/II: python-rtslib-fb
    [.] MIR ack - needs packaging/lintian fixes
    [.] Security ack - upstream fix done

    - Upstream version v2.1.73 incudes the security fix.

    Suggesting:
    https://salsa.debian.org/openstack-team/python/python-rtslib-fb/-/merge_requests/2
    https://salsa.debian.org/openstack-team/python/python-rtslib-fb/-/merge_requests/3

    - Might not need fix for LP: #1865037 (put a comment, waiting Debian)
    - Highlighted @jamespage in both MR in salsa (hopefully he can help)

I: tcmu
    [.] MIR ack
    [+] Security ack - but needs dbus fix

I: urwid
    [.] MIR ack
    [.] Security: ack

Only thing missing: tcmu fix and wait changes to be accepted so we can put all those packages on sync (and then do the MIR if everybody is on the same page).

For the tcmu DBUS fix:

"""
- The dbus policy allows all users to call
    org.kernel.TCMUService1.HandlerManager1.RegisterHandler, which doesn't seem
    desirable. I don't think there is a direct security impact from this, as
    external handlers need to be privileged in order to own the type-specific
    well-known name on the system bus, and the call will return an error if
    called before that name is owned. But I think this should only be callable
    as the root user.
"""

I'm not taking action as we should wait upstream to take action on:

https://github.com/open-iscsi/tcmu-runner/issues/582

and, if there isn't a direct security impact I think it would be ok for the MIR to continue despite this change.

With that in mind:

I: tcmu
    [.] MIR ack
    [.] Security ack - dbus fix orthogonal (upstream bug)

    - https://github.com/open-iscsi/tcmu-runner/issues/582

There is nothing else to be done here but to wait Debian to accept my merge proposals. I'll keep this updated based on salsa MR discussions (if any).

-rafaeldtinoco

CURRENT STATUS

Targets:

- I: ceph-iscsi
- II: targetcli-fb

Summary for the current state:

I: ceph-iscsi
    [-] MIR ack (if everything else is)

I/II: python-configshell-fb (linux-blocks-teams) - DONE
    [.] MIR ack
    [.] Security ack - needs DEP8 inclusion

    For Debian, Suggested:
    - https://salsa.debian.org/linux-blocks-team/python-configshell-fb/-/merge_requests/3/
    All MR got merged into debian/master (crazy) so I did 3 MRs
    again with same contents but mistake fixed. E-mailed debian
    maintainer to warn about the issue: gbp gives a merge URL
    with default debian/master for all git pushes you do.

    Whitelisted in git-ubuntu for importing

    Uploaded version 1:1.1.28-1ubuntu1 with same source code merged in Debian unstable.
    (did like if it was a syncpackage)

    DONE: 1:1.1.28-1ubuntu1 (groovy/universe)

II: targetcli-fb (linux-blocks-teams)
    [.] MIR ack - needs DEP8 and services/sockets fix
    [.] Security nack->ack - 2 upstream fixes done

    For Debian, Suggested:
    - https://salsa.debian.org/linux-blocks-team/targetcli-fb/-/merge_requests/8
    Here the same thing happened (about debian/master). I have also
    warned Debian maintainer about it and provided the correct MRs
    triple.

    Uploaded version 1:2.1.53-1ubuntu1 with same source code from Debian
    (did like if it was a sync, but warned some changes were dropped)

    DONE: 1:2.1.53-1ubuntu1 (groovy/universe)

I/II: python-rtslib-fb (openstack team)
    [.] MIR ack - needs packaging/lintian fixes
    [.] Security ack - upstream fix done

    - Upstream version v2.1.73 incudes the security fix.

    Suggesting:
    https://salsa.debian.org/openstack-team/python/python-rtslib-fb/-/merge_requests/2
    https://salsa.debian.org/openstack-team/python/python-rtslib-fb/-/merge_requests/3

    - Might not need fix for LP: #1865037 (put a comment, waiting Debian)
    - Highlighted @jamespage in both MR in salsa (hopefully he can help)

    DEBIAN OPENSTACK TEAM: Will verify my MR after the next OS release
    UBUNTU: working on it

I: tcmu
    [.] MIR ack
    [.] Security ack - but needs dbus fix

    I'm not taking action as we should wait upstream to take action on:

    https://github.com/open-iscsi/tcmu-runner/issues/582

    CURRENT SYNC: 1.5.2-5build1 (groovy/universe)

I: urwid
    [.] MIR ack
    [.] Security: ack

FINAL STATUS:

Missing python-rtslib-fb update in groovy only for everything to be cleared for MIR.
(working on it)

CURRENT STATUS

Targets:

- I: ceph-iscsi
- II: targetcli-fb

Summary for the current state:

I: ceph-iscsi
    [.] MIR ack (if everything else is)

I/II: python-configshell-fb (linux-blocks-teams) - DONE
    [.] MIR ack
    [.] Security ack - needs DEP8 inclusion

    For Debian, Suggested:
    - https://salsa.debian.org/linux-blocks-team/python-configshell-fb/-/merge_requests/3/

    All MR got merged into debian/master (crazy) so I did 3 MRs
    again with same contents but mistake fixed. E-mailed debian
    maintainer to warn about the issue: gbp gives a merge URL
    with default debian/master for all git pushes you do.

    Whitelisted in git-ubuntu for importing

    Uploaded version 1:1.1.28-1ubuntu1 with same source code merged in Debian unstable.
    (did like if it was a syncpackage)

    DONE: 1:1.1.28-1ubuntu1 (groovy/universe)

II: targetcli-fb (linux-blocks-teams)
    [.] MIR ack - needs DEP8 and services/sockets fix
    [.] Security nack->ack - 2 upstream fixes done

    For Debian, Suggested:
    - https://salsa.debian.org/linux-blocks-team/targetcli-fb/-/merge_requests/8
    Here the same thing happened (about debian/master). I have also
    warned Debian maintainer about it and provided the correct MRs
    triple.

    Uploaded version 1:2.1.53-1ubuntu1 with same source code from Debian
    (did like if it was a sync, but warned some changes were dropped)

    DONE: 1:2.1.53-1ubuntu1 (groovy/universe)

I/II: python-rtslib-fb (openstack team)
    [.] MIR ack - needs packaging/lintian fixes
    [.] Security ack - upstream fix done

    - Upstream version v2.1.73 includes the security fix.

    Suggesting:
    https://salsa.debian.org/openstack-team/python/python-rtslib-fb/-/merge_requests/2
    https://salsa.debian.org/openstack-team/python/python-rtslib-fb/-/merge_requests/3

    - Might not need fix for LP: #1865037 (put a comment, waiting Debian)
    - Highlighted @jamespage in both MR in salsa (hopefully he can help)

    DEBIAN OPENSTACK TEAM: Will verify my MR after the next OS release
    DONE: 2.1.73-1ubuntu1 (groovy/universe)

I: tcmu
    [.] MIR ack
    [.] Security ack - but needs dbus fix

    I'm not taking action as we should wait upstream to take action on:

    https://github.com/open-iscsi/tcmu-runner/issues/582

    CURRENT SYNC: 1.5.2-5build1 (groovy/universe)

I: urwid
    [.] MIR ack
    [.] Security: ack

FINAL STATUS:

Ready for [main] inclusion.

ceph-iscsi is still in security review, but other than that for use case II everything is indeed ready. I was updating the bug states.
That is the set of python-configshell-fb + python-rtslib-fb + targetcli-fb + tcmu + urwid

@Radael - would you mind doing a seed change for these to happen?

P.S. I'll double check and ensure we are indeed subscribed to all packages ...

Subscriptions are ok.

I have pinged the security Team on ceph-iscsi and Rafael agreed to make the seed change.

@rafael - as soon as the seed change is active and shows up in component mismatches please subscribe ubuntu-archive here to resolve.

The expected four packages for use case II show up in component mismatches after the seed change:

python-configshell-fb: python3-configshell-fb
MIR: #1854362 (In Progress)
[Reverse-Depends: targetcli-fb (Uploader: rafaeldtinoco)]
python-rtslib-fb: python3-rtslib-fb
MIR: #1854362 (In Progress)
[Reverse-Depends: targetcli-fb (Uploader: rafaeldtinoco)]
targetcli-fb: targetcli-fb
MIR: #1854362 (In Progress)
[Reverse-Depends: Ubuntu.Groovy supported-misc-servers seed]
urwid: python-urwid-doc python3-urwid
MIR: #1854362 (In Progress)
[Reverse-Depends: Rescued from urwid (Uploader: doko), python3-configshell-fb]

@ubuntu-archive - please promote them.

Override component to main
python-configshell-fb 1:1.1.28-1ubuntu1 in groovy: universe/misc -> main
python3-configshell-fb 1:1.1.28-1ubuntu1 in groovy amd64: universe/python/optional/100% -> main
python3-configshell-fb 1:1.1.28-1ubuntu1 in groovy arm64: universe/python/optional/100% -> main
python3-configshell-fb 1:1.1.28-1ubuntu1 in groovy armhf: universe/python/optional/100% -> main
python3-configshell-fb 1:1.1.28-1ubuntu1 in groovy i386: universe/python/optional/100% -> main
python3-configshell-fb 1:1.1.28-1ubuntu1 in groovy ppc64el: universe/python/optional/100% -> main
python3-configshell-fb 1:1.1.28-1ubuntu1 in groovy riscv64: universe/python/optional/100% -> main
python3-configshell-fb 1:1.1.28-1ubuntu1 in groovy s390x: universe/python/optional/100% -> main
8 publications overridden.

Override component to main
python-rtslib-fb 2.1.73-1ubuntu2 in groovy: universe/misc -> main
python3-rtslib-fb 2.1.73-1ubuntu2 in groovy amd64: universe/python/optional/100% -> main
python3-rtslib-fb 2.1.73-1ubuntu2 in groovy arm64: universe/python/optional/100% -> main
python3-rtslib-fb 2.1.73-1ubuntu2 in groovy armhf: universe/python/optional/100% -> main
python3-rtslib-fb 2.1.73-1ubuntu2 in groovy i386: universe/python/optional/100% -> main
python3-rtslib-fb 2.1.73-1ubuntu2 in groovy ppc64el: universe/python/optional/100% -> main
python3-rtslib-fb 2.1.73-1ubuntu2 in groovy riscv64: universe/python/optional/100% -> main
python3-rtslib-fb 2.1.73-1ubuntu2 in groovy s390x: universe/python/optional/100% -> main
8 publications overridden.

Override component to main
targetcli-fb 1:2.1.53-1ubuntu1 in groovy: universe/misc -> main
targetcli-fb 1:2.1.53-1ubuntu1 in groovy amd64: universe/admin/optional/100% -> main
targetcli-fb 1:2.1.53-1ubuntu1 in groovy arm64: universe/admin/optional/100% -> main
targetcli-fb 1:2.1.53-1ubuntu1 in groovy armhf: universe/admin/optional/100% -> main
targetcli-fb 1:2.1.53-1ubuntu1 in groovy i386: universe/admin/optional/100% -> main
targetcli-fb 1:2.1.53-1ubuntu1 in groovy ppc64el: universe/admin/optional/100% -> main
targetcli-fb 1:2.1.53-1ubuntu1 in groovy riscv64: universe/admin/optional/100% -> main
targetcli-fb 1:2.1.53-1ubuntu1 in groovy s390x: universe/admin/optional/100% -> main
8 publications overridden.

Override component to main
urwid 2.1.0-4 in groovy: universe/python -> main
python-urwid-doc 2.1.0-4 in groovy amd64: universe/doc/optional/100% -> main
python-urwid-doc 2.1.0-4 in groovy arm64: universe/doc/optional/100% -> main
python-urwid-doc 2.1.0-4 in groovy armhf: universe/doc/optional/100% -> main
python-urwid-doc 2.1.0-4 in groovy i386: universe/doc/optional/100% -> main
python-urwid-doc 2.1.0-4 in groovy ppc64el: universe/doc/optional/100% -> main
python-urwid-doc 2.1.0-4 in groovy riscv64: universe/doc/optional/100% -> main
python-urwid-doc 2.1.0-4 in groovy s390x: universe/doc/optional/100% -> main
python3-urwid 2.1.0-4 in groovy amd64: universe/python/optional/100% -> main
python3-urwid 2.1.0-4 in groovy arm64: universe/python/optional/100% -> main
python3-urwid 2.1.0-4 in groovy armhf: universe/python/optional/100% -> main
python3-urwid 2.1.0-4 in groovy ppc64el: universe/python/optional/100% -> main
python3-urwid 2.1.0-4 in groovy riscv64: universe/python/optional/100% -> main
python3-urwid 2.1.0-4 in groovy s390x: universe/python/optional/100% -> main
14 publications overridden.

I reviewed ceph-iscsi 3.4-0ubuntu2 as checked into focal. This shouldn't
be considered a full audit but rather a quick gauge of maintainability.

ceph-iscsi is a set of tools for managing LIO gateways for Ceph. It
consists of 2 services providing REST APIs - one for obtaining gateway
node statistics and another for providing the gateway API, restoring
gateway state and keeping gateway nodes in sync. Under the hood, it uses
rtslib for configuring the gateway via the LIO interfaces, and Ceph
backstores are implemented in userspace (in tcmu). A command line tool is
provided for managing the gateway nodes, which communicates with the
gateway node's API.

- No CVE history.
- All build-depends in main except for: python3-configshell-fb,
  python3-mock, python3-pytest, python3-rtslib-fb. Only
  python3-configshell-fb and python3-rtslib-fb are required at runtime
  (this MIR).
- Depends on python3-openssl (crypto), python3-requests (HTTP) and
  python-flask (werkzeug based web framework).
- Maintainer scripts just contain some debhelper snippets from dh_python3,
  dh_installinit and dh_installsystemd.
- Provides 2 services:
 - rbd-target-gw:
  - This is a simple flask app that provides a REST API with 2 endpoints
    on port 9287 (configurable) to obtain gateway statistics.
  - The /metrics endpoint just provides a formatted summary of a bunch of
    properties from configfs (via rtslib).
 - rbd-target-api:
  - This is a flask app that provides a REST API on port 5000
    (configurable) for configuring the gateways and restoring their state.
  - Some of the API is used by gwcli, and some of it is considered
    "internal" for the purposes of syncrhonizing configuration on gateway
    nodes.
 - Both services run as root.
 - The APIs are publicly available by default, although this is
   configurable.
 - The APIs are exported using HTTP by default. They can be configured to
   use HTTPS.
- Contains 2 systemd units for starting the 2 REST services as part of
  multi-user.target. Both run as root, but do specify the
  PrivateDevices=yes, ProtectHome=true, ProtectSystem=full,
  PrivateTmp=true options.
- No D-Bus services.
- No setuid binaries.
- 3 binaries in PATH: the 2 services (rbd-target-api, rbd-target-gw) and a CLI
  tool (gwcli) for managing the Ceph iSCSI gateway.
- No sudo fragments.
- No policykit.
- No udev rules.
- Some limited unit tests that test a few classes in the ceph_iscsi_config
  python package. These run as part of the build and all pass. No
  autopkgtests.
- No cronjobs.
- Build logs are clean - just some deprecation warnings that seem to come
  from pyudev. Only lintian warnings are a couple of
  binary-without-manpage warnings for the 2 services.

- Spawns subprocesses using subprocess.check_output.
 - gwcli uses the default shell=False
 - rbd-target-api uses shell=True, but doesn't seem to be using it with
   arguments from untrusted sources.
 - There is a subprocess.check_output helper in ceph_iscsi_config/utils.py
   (shellcommand) that appears to be unused.
- Opens files for reading in a few places using a mixture of hard-coded
  paths and paths specified in the config file
  (/etc/ceph/iscsi-gateway.cfg).
  - One API endpoin...

This was an ack and thereby ceph-iscsi this is ready as well

Please make the change that pulls in ceph-iscsi and ensure you are subscribed to the package to "own" it as the archive admins will rightfully insist on that before promotion :-)

@Jamespage - I think this is up to you to push now right?

This was kind of forgotten, James/Chris don't you need that anymore?

I've added the bug subscription for ceph-iscsi.

AFAICS ceph-iscsi still needs tcmu, which is ready except waiting for https://github.com/open-iscsi/tcmu-runner/issues/582
AFAICS no one continue on that yet, I'm updating the case to better reflect that.
James please re-assign as-needed to get these steps done.

There has been not further update for too long, for now we consider it invalid.
Feel free to re-open if there is effort backing it up and motivation to bring it to main.