[Desktop-packages] [Bug 1978890] Re: FIPS/OEM installation compatibility is unclear to the end-user

2022-07-26 Thread Lucas Albuquerque Medeiros de Moura
We discussed this on the UA team and we believe we can warn the user of
the potential problems of enabling FIPS we using a OEM kernel, but we
don't think we should block this on the UA side, since users could still
be aware of the risk and follow through with the procedure.

However, before we deliver this through UA, we believe we need to sort
the GRUB_FLAVOUR_ORDER scenario. Otherwise we will warn the user and
even if they want to proceed with FIPS, the will end up in the OEM
kernel regardless.

But let us know if you think we should definitely block enabling FIPS on
a machine running a OEM kernel.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ubuntu-drivers-common in Ubuntu.
https://bugs.launchpad.net/bugs/1978890

Title:
  FIPS/OEM installation compatibility is unclear to the end-user

Status in subiquity package in Ubuntu:
  In Progress
Status in ubiquity package in Ubuntu:
  New
Status in ubuntu-advantage-tools package in Ubuntu:
  New
Status in ubuntu-drivers-common package in Ubuntu:
  New
Status in update-manager package in Ubuntu:
  New

Bug description:
  [Overall Summary]

  Converting to cover all oem/fips compatibility issues with
  ua/installers/update-manager. These projects are mostly silo'd, so
  when they all converge it creates a confusing and frustrating
  experience for the user.

  At it's core, the problem is that both fips and oem us
  GRUB_FLAVOUR_ORDER to select the preferred kernel to boot from,
  disregarding versioning.

  The main issues are:
  1. ubuntu-drivers should not attempt to `oem-ify` a `fipsified` machine
  2. ua tool should not attempt to `fipsify` an oem machine
  3. subiquity should mention that drivers page is potentially making machine 
realtime & fips incompatible

  
  Below are some reproducible examples of issues:

  ---
  (Subiquity installer case)
  [Summary]
  A recent change to the subiquity snap adds support for installing oem drivers 
at time of instance install. If the user installs these packages, then attempts 
to install the fips packages post-install, fips will install as expected, but 
the system will always boot to the oem kernel.

  [Expected Behavior]
  Messaging should clearly indicate that installing the oem packages will make 
the environment incompatible with fips/RT kernel/ etc. 

  [Observed Behavior]
  Subiquity just offers additional drivers, without clarifying the 
compatibility complications.

  [Replication Steps]
  (Using Dell Inc. Precision 7920 Tower/060K5C)
  1. Install from current focal ISO
  2. Confirm driver installation on the oem gui page
  3. Install ua client/fips
  4. Reboot
  5. Observe kernel version (oem)

  ---
  (update-manager case)
  [Summary]
  A feature was added to allow for post-install enablement for oem-enabled 
devices via update manager:
  https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050

  While this works great for some situations, it can lead to users
  unexpectedly installing the oem meta package + associated kernel,
  overwriting an existing fips installation, as the "Improved hardware
  support" bundle may not be noticed when operating update-manager

  [Expected Behavior]
  For non linux-generic running installs, the post-install oem enablement 
functionality should not trigger, nor should it add the additional repositories 
to the client's sources.list.d.

  [Observed Behavior]
  sources.list.d is updated and "Improved hardware support" is allowed as an 
option in update-manager, which leads to clients unexpectedly losing compliance 
in fips environments.

  [Replication Steps]
  (Using Dell Inc. Precision 7920 Tower/060K5C)
  1. Install from current focal ISO
  2. Attach a ua subscription
  3. Enable the fips-updates service
  4. Reboot the system, login the desktop and wait for a while. The 
notification will pop up and it will show "Improved hardware support" on the 
certified machines that has the OEM metapackage support.
  5. Click through the update-manager prompt and install the oem packages
  6. Reboot check fips status

  oem's config in /etc/default/grub.d/* does not have a number prefix,
  and thus will always override 99-ubuntu-fips.cfg when calling update-
  grub.

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


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1965138] [NEW] Desktop application should check for service available information before listing it

2022-03-16 Thread Lucas Albuquerque Medeiros de Moura
Public bug reported:

Currently, it seems that software-properties is incorrectly assuming
that both ESM and Livepatch services can be enabled in a Jammy machine.
Those services are not yet available in Jammy and we are attaching an
image showing that the Desktop message is that we had an error enabling
then and that the user should try again.

It seems that software-proporties source `/var/lib/ubuntu-
advantage/status.json` and assumes the services is available if it
appears on the services list and the `entitled` field has the `yes`
value. However, it is perfectly possible for a service to be entitled to
an user, but not available in the user's machine.

We are now suggesting that software-properties also looks at the
`available` field in the services json output to make that assumption,
this will probably solve the issue we are seeing on Jammy.

Another approach would be using the output of `ua status --format json`
directly. However, this command will make a request to the contract's
server if the user is unattached and maybe it is not wise to use it in
that context. However, the output of that command only show services
that are available, so we would not need to apply that extra available
filter to it.

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New

** Attachment added: "jammy-desktop-error.png"
   
https://bugs.launchpad.net/bugs/1965138/+attachment/5569662/+files/jammy-desktop-error.png

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to software-properties in Ubuntu.
https://bugs.launchpad.net/bugs/1965138

Title:
  Desktop application should check for service available information
  before listing it

Status in software-properties package in Ubuntu:
  New

Bug description:
  Currently, it seems that software-properties is incorrectly assuming
  that both ESM and Livepatch services can be enabled in a Jammy
  machine. Those services are not yet available in Jammy and we are
  attaching an image showing that the Desktop message is that we had an
  error enabling then and that the user should try again.

  It seems that software-proporties source `/var/lib/ubuntu-
  advantage/status.json` and assumes the services is available if it
  appears on the services list and the `entitled` field has the `yes`
  value. However, it is perfectly possible for a service to be entitled
  to an user, but not available in the user's machine.

  We are now suggesting that software-properties also looks at the
  `available` field in the services json output to make that assumption,
  this will probably solve the issue we are seeing on Jammy.

  Another approach would be using the output of `ua status --format
  json` directly. However, this command will make a request to the
  contract's server if the user is unattached and maybe it is not wise
  to use it in that context. However, the output of that command only
  show services that are available, so we would not need to apply that
  extra available filter to it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1965138/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp