[Group.of.nepali.translators] [Bug 1828901] Re: add PTY support for runuser

2020-02-15 Thread Eric Desrochers
The sosreport juju plugin refactoring has been simplified.

For now, we don't expect the juju plugin to drop privileges any time
soon.

Thanks !

** Changed in: util-linux (Ubuntu Xenial)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1828901

Title:
  add PTY support for runuser

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  Won't Fix
Status in util-linux package in Debian:
  Fix Released

Bug description:
  [IMPACT]

  [TEST CASE]

  [REGRESSION POTENTIAL]

  [OTHER INFORMATION]

  Debbug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922

  This is fixing a CVE vulnerability:
  https://security-tracker.debian.org/tracker/CVE-2016-2779

  Restricting ioctl on the kernel side seems the better approach, patches have 
been posted to kernel-hardening list
  http://www.openwall.com/lists/oss-security/2016/02/27/1
  https://marc.info/?l=util-linux-ng&m=145694736107128&w=2
  2.31 introduces a new --pty option to separate privileged and unprivileged
  shells (not enabled by default and the cli switch is necessary).

  [ORIGINAL DESCRIPTION]
  After a discussion with security team on what would be their recommended way 
to run command as 'juju-user' inside the sosreport juju plugin which is run as 
root, in order to avoid using 'sudo' or 'su' command.

  The recommendation was to use 'runuser -P'

  runuser PTY support is present in Bionic and late, but not in Xenial.

  I'm opening this bug in the effort to update util-linux/runuser code
  in Xenial to add the PTY support.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1828901/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1862830] Re: Update sosreport to 3.9

2020-02-15 Thread Eric Desrochers
** Bug watch added: Debian Bug tracker #951392
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951392

** Also affects: sosreport (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951392
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1862830

Title:
  Update sosreport to 3.9

Status in sosreport package in Ubuntu:
  In Progress
Status in sosreport source package in Xenial:
  New
Status in sosreport source package in Bionic:
  New
Status in sosreport source package in Eoan:
  New
Status in sosreport source package in Focal:
  In Progress
Status in sosreport package in Debian:
  Unknown

Bug description:
  [Impact]

  sosreport 3.9 is now released.

  It would be great to find sosreport v3.9 in supported stable releases,
  and active development release considering the fact that the releasea
  (especially LTSes) are going to be supported for a couple of years
  still.

  Sosreport is widely use by Canonical support team to troubleshoot UA
  (Ubuntu Advantage) customer, other vendors and community users.

  Just like we did for :
  - v3.5 (LP: #1734983)
  - v3.6 (LP: #1775195)

  [Test Case]

  [Regression Potential]

  [Other Informations]

  * Release note:
  https://github.com/sosreport/sos/releases/tag/3.9

  [Original Description]

  A new version of sosreport upstream (v3.9) will be released soon.
  This bug is to track activities to update sosreport in Ubuntu stable + Active 
Devel release.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp


[Group.of.nepali.translators] [Bug 1862938] Re: Enable late loading of microcode by default

2020-02-15 Thread Dimitri John Ledkov
I'm trying to fix the case when users/manufacturers failed to
provide/install uefi capsule update on the motherboard, failed to first-
boot with up to date microcode, and thus remain unsecured, whilst one
can install microcode. In bare-metal cloud context, late loading of
microcode can be done as the line of last defence to apply microcode.

** Changed in: intel-microcode (Ubuntu Focal)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1862938

Title:
  Enable late loading of microcode by default

Status in intel-microcode package in Ubuntu:
  Fix Released
Status in intel-microcode source package in Xenial:
  New
Status in intel-microcode source package in Bionic:
  New
Status in intel-microcode source package in Eoan:
  Fix Committed
Status in intel-microcode source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * An explanation of the effects of the bug on users and

   * justification for backporting the fix to the stable release.

   * In addition, it is helpful, but not required, to include an
 explanation of how the upload fixes this bug.

   * Normally intel microcode is applied "early" for an uncompressed
  prepended initramfs archive. However, on systems booting without an
  initrd, or a missbuilt one, microcode might not get applied. In that
  case, we need to attempt loading microcode late which may give users
  security protection against CPU vulnerabilities which they might
  otherwise be lacking. In an ideal world, everyone would apply their
  bios/OEM updates with microcode updates in a timely fashion and then
  we wouldn't need to update CPU microcode from userspace at all.

  [Test Case]

   * Install updated package
   * Reobot
   * Observe early application of microcode

  $ journalctl -b | grep microcode
  Feb 12 12:02:48 ottawa kernel: microcode: microcode updated early to revision 
0xd6, date = 2019-10-03

   * Remove /usr/share/initramfs-tools/hooks/intel_microcode to prevent correct 
generation of early microcode updates
   * Rebuild initrd with update-initramfs -u
   * Reboot
   * Observe in dmesg that late loading of microcode is performed

  $ journalctl -b | grep microcode
  Feb 12 12:32:54 ottawa kernel: TAA: Vulnerable: Clear CPU buffers attempted, 
no microcode
  Feb 12 12:32:54 ottawa kernel: MDS: Vulnerable: Clear CPU buffers attempted, 
no microcode
  Feb 12 12:32:54 ottawa kernel: microcode: sig=0x506e3, pf=0x20, revision=0xc6
  Feb 12 12:32:54 ottawa kernel: microcode: Microcode Update Driver: v2.2.
  Feb 12 12:32:57 ottawa kernel: microcode: updated to revision 0xd6, date = 
2019-10-03
  Feb 12 12:32:57 ottawa kernel: x86/CPU: CPU features have changed after 
loading microcode, but might not take effect.
  Feb 12 12:32:57 ottawa kernel: microcode: Reload completed, microcode 
revision: 0xd6

  (Note the lack of "early" in above messages)

  [Regression Potential]

   * Application of microcode is a risky operation, especially if the
  cores are busy. Hence we prefer bios updates & early microcode
  updates, and those will remain the place. The late loading of
  microcode is really here for the cases were the previous two update
  strategies have failed. For example, from time to time, certain
  microcode updates are pulled or get blacklisted from late loading.

  [Other Info]
   
   * The majority of our users on bare-metal machines boot correctly with early 
microcode updates.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1862938/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp