Re: Updates to cacti for CVE-2023-39361 (CVSS 9.8)?

[Alex Murray]

Hi chuegen,

As cacti is in the universe component of the repository, it is community
maintained and therefore there is no timeframe as to when such a package
will be patched in Ubuntu nor any clear indication if a community member
is working on this at this time.

You can see the status of this CVE in the Ubuntu CVE Tracker at
https://ubuntu.com/security/CVE-2023-39361

Thanks,
Alex

On Tue, 2023-09-12 at 11:36:47 -0500, chue...@pentics.com wrote:

> Hi there, 
>
> The Cacti project provided an announcement of a CVSS 9.8 SQL injection
> bug against Cacti (fixed in 1.2.25).  Is this being worked, and how long
> should I expect before a package becomes available in the Ubuntu 22.04
> security stream?  For now, I have disabled the functionality in question
> while I await a package update (and I'd like to avoid having to go with
> a local version of the updated package if it will be relatively soon). 
>
> -c
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Apache2 Vulnerability

[Alex Murray]

Hi Daniel

In Ubuntu we generally do not upgrade to new package versions to fix
security issues but instead backport the individual fixes. As such you
should not expect to see say apache 2.4.56 in Ubuntu 23.04. Instead we
just add the minimal change needed to fix the vulnerability on top of
the existing 2.4.55 version.

Regarding these two CVEs in question, you can see the status for each of
these vulnerabilities in Ubuntu at

https://ubuntu.com/security/CVE-2023-27522

and

https://ubuntu.com/security/CVE-2023-25690

respectively.

Both have already been patched and updates released back in March of
this year.

For more details on how package updates work in Ubuntu, I recommend
taking a look at
https://ubuntu.com/blog/ubuntu-updates-releases-and-repositories-explained

Thanks,
Alex


On Thu, 2023-09-07 at 17:25:27 +, Daniel Johnston wrote:

> Hello,
>
> I was wondering on when you plan to upgrade Apache from 2.4.55 to at least 
> 2.4.56 to address the vulnerabilities with Apache?
> We have been checking weekly for a number of months now.
> Changes with Apache 2.4.56
>
>   *) SECURITY: CVE-2023-27522: Apache HTTP Server: mod_proxy_uwsgi
>  HTTP response splitting (cve.mitre.org)
>  HTTP Response Smuggling vulnerability in Apache HTTP Server via
>  mod_proxy_uwsgi. This issue affects Apache HTTP Server: from
>  2.4.30 through 2.4.55.
>  Special characters in the origin response header can
>  truncate/split the response forwarded to the client.
>  Credits: Dimas Fariski Setyawan Putra (nyxsorcerer)
>
>   *) SECURITY: CVE-2023-25690: HTTP request splitting with
>  mod_rewrite and mod_proxy (cve.mitre.org)
>  Some mod_proxy configurations on Apache HTTP Server versions
>  2.4.0 through 2.4.55 allow a HTTP Request Smuggling attack.
>  Configurations are affected when mod_proxy is enabled along with
>  some form of RewriteRule or ProxyPassMatch in which a non-specific
>  pattern matches some portion of the user-supplied request-target (URL)
>  data and is then re-inserted into the proxied request-target
>  using variable substitution. For example, something like:
> RewriteEngine on
> RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1;; [P]
> ProxyPassReverse /here/  http://example.com:8080/
>  Request splitting/smuggling could result in bypass of access
>  controls in the proxy server, proxying unintended URLs to
>  existing origin servers, and cache poisoning.
>  Credits: Lars Krapf of Adobe
>
> [cid:image001.jpg@01D9E186.60BF0920]
> Daniel Johnston
> IT Systems Administrator
>  |
> Premier Credit Union
> [cid:image002.png@01D9E186.60BF0920]
> 515-245-3541
>  |
> [cid:image003.png@01D9E186.60BF0920]
> dani...@premiercu.org
> [cid:image004.png@01D9E186.60BF0920]
> www.PremierCU.org
> [cid:image005.png@01D9E186.60BF0920]
> [cid:image006.png@01D9E186.60BF0920]
> [cid:image007.png@01D9E186.60BF0920]
> 800 9th St
> ,
> Des Moines
> ,
> Iowa
>
> 50309
> Leave us a Review on 
> Google!
> [cid:image008.jpg@01D9E186.60BF0920]
> This e-mail, including attachments, is covered by the Electronic 
> Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential, and may be 
> legally privileged. If you are not the intended recipient, you are hereby 
> notified that any retention, dissemination, distribution, or copying of this 
> communication is strictly prohibited. Please reply to the sender if you 
> received this message in error, and then please delete it. Thank you.
>
>
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 

Re: Plans to update rsync?

[Alex Murray]

Hi Robert

On Fri, 2023-01-20 at 19:24:19 +0100, Robert Landers wrote:

> Hello,
>
> I could not, for the life of me, figure out how to report a bug or
> request a package to be updated (other than emailing this list or
> getting on IRC). But thought I'd give this a try.

The easiest way to report a bug is to simply run the following from a
terminal:

ubuntu-bug rsync

Please ensure you include as much information as possible in the bug
report - I tried looking at
https://download.samba.org/pub/rsync/NEWS and couldn't find any mention
of this sort of issue so any help you could give on pointing the
developers to the associated upstream bug report / fix would be great.

>
> In rsync 3.2.3, there is a bug when the remote shell is zsh, it sends
> some unescaped characters when using `--chown` flag.
>
> This is fixed in 3.2.5.
>
> Currently, Jammy is shipping 3.2.3, are there any plans to upgrade
> rsync?

Ubuntu does not upgrade package versions during the lifetime of a
release - instead we will backport fixes for bugs / security issues as
appropriate.

>
> The only known workaround is to install an 'out-of-tree' version of
> rsync or switch the remote shell to bash.
>
> Robert Landers
> Software Engineer
> Utrecht NL
>
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: ntfs-3g app deadlock bug report

[Alex Murray]

Hi

Thanks for reporting this issue - in general it is better to report bugs
via launchpad than email (e.g. by running the following command (without
the quotation marks) in a terminal: "ubuntu-bug ntfs-3g" or by
https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+filebug)

I notice you also appear to have reported this to the upstream nfts-3g
project at https://github.com/tuxera/ntfs-3g/issues/56 but have had no
response.

However, my initial thoughts when looking at this is that it appears you
can trigger a livelock within the kernel from an unprivileged user in
userspace - as such I wonder if this is a bug in the FUSE subsystem
within the Linux kernel and hence whether it should be reported to the
upstream kernel developers as well? As per
https://www.kernel.org/doc/html/v4.15/admin-guide/reporting-bugs.html it
would appear that this should be reported to the following email
addresses (assuming this is a real kernel bug rather than a bug within
the ntfs-3g userspace project):

$ ./scripts/get_maintainer.pl fs/fuse/fuse_i.h
Miklos Szeredi  (maintainer:FUSE: FILESYSTEM IN USERSPACE)
linux-fsde...@vger.kernel.org (open list:FUSE: FILESYSTEM IN USERSPACE)
linux-ker...@vger.kernel.org (open list)

Thanks,
Alex

On Sat, 2022-12-10 at 13:02:41 +0900, 박영준 wrote:

> Hi I find live lock bug in ntfs-3g app.
> I post it but not respond from its public repos.
> so I report it this mailing list
>
> the bug I found is written below.
>
>
> [Environment]
> 22.04 5.15.0-43-generic ubuntu kernel.
> ntfs-3g version ntfs-3g 2021.8.22 integrated FUSE 28 - Third Generation NTFS 
> Driver
> [Problem]
> I bumped on livelock and analyze it. and concluded that it is needed to be 
> fixed.
> it happens when 3 operation concurrently progressing.
>
> usb detach by user. and kernel detect it.
> mount.ntfs umount request & device release operation
> pool-udisksd umount operation.
>
> [Conclusion]
>
> mounted target device file must be released after /dev/fuse release. it makes 
> deadlocky scenario.
> fuse file system "fuse_simple_request" should not be waiting forever. it is 
> hard to solve this situation by interrupting application. huntask panic 
> configuration make user kernel panic. user
> don't know why.
>
> [Analysis]
> I got a kernel crash dump file. and analyze it.
> here is the scenario description.
>
> kworker detect usb is detached from computer.
> it is blocked by umount operation (pool-udiskd)
> PID: 8 TASK: 88810029e400 CPU: 0 COMMAND: "kworker/0:1"
> 0 [c906f6f0] __schedule at 81d57c0d
> 1 [c906f778] schedule at 81d57fae
> 2 [c906f798] rwsem_down_read_slowpath at 81d5a2de
> 3 [c906f830] down_read at 81d5a373 // wait s_umount
> 4 [c906f848] get_super at 813799ca
> 5 [c906f878] fsync_bdev at 815c6f46
> 6 [c906f8a0] delete_partition at 815e9328
> 7 [c906f8c0] blk_drop_partitions at 815e9b3e
> 8 [c906f8e8] del_gendisk at 815e75f1 // lock mutex
> 9 [c906f930] sd_remove at 818cd325
> 10 [c906f958] __device_release_driver at 8184006f
> 11 [c906f990] device_release_driver at 818400a9
> 12 [c906f9b0] bus_remove_device at 8183f28e
> 13 [c906f9d8] device_del at 818399ac
> 14 [c906fa28] __scsi_remove_device at 818c2628
> 15 [c906fa50] scsi_forget_host at 818c029f
> 16 [c906fa70] scsi_remove_host at 818b3727
> 17 [c906fa98] usb_stor_disconnect at c0659b20 [usb_storage]
> 18 [c906fac0] usb_unbind_interface at 8194ef30
> 19 [c906fb18] __device_release_driver at 8184006f
> 20 [c906fb50] device_release_driver at 818400a9
> 21 [c906fb70] bus_remove_device at 8183f28e
> 22 [c906fb98] device_del at 818399ac
> 23 [c906fbe8] usb_disable_device at 8194cdce
> 24 [c906fc30] usb_disconnect.cold at 81d19e09
> 25 [c906fc80] hub_port_connect at 81944bb8
> 26 [c906fd00] hub_port_connect_change at 819454b1
> 27 [c906fd70] port_event at 81945d77
> 28 [c906fe08] hub_event at 819460a7
> 29 [c906fe78] process_one_work at 810d9e7b
> 30 [c906fec8] worker_thread at 810da073
> 31 [c906ff10] kthread at 810e1cba
> 32 [c906ff50] ret_from_fork at 81004bc2
>
> 3 [c906f830] down_read at 81d5a373
> c906f838: [888154d36800:kmalloc-2k] c906f870
> c906f848: get_super+154
>
> it request umount. and release /dev/sdc file before release /dev/fuse. but. 
> it is blocked by usb detach.
> PID: 18681 TASK: 88810e5b8000 CPU: 1 COMMAND: "mount.ntfs"
> 0 [c9ea7c50] __schedule at 81d57c0d
> 1 [c9ea7cd8] schedule at 81d57fae
> 2 [c9ea7cf8] schedule_preempt_disabled at 

Re: Extended call for Ubuntu Technical Board candidates

[Alex Murray]

Hi folks,

I'm Alex Murray (alexmurray on Launchpad/amurray on IRC) and have been a
part of the Ubuntu community as a long-time user and enthusiast since
back in 2006. In 2018 I was privileged to join Canonical as the Ubuntu
Security Tech Lead and have worked as part of that amazing team ever
since. I have a passion for making Ubuntu as secure *and* usable
out-of-the-box whilst also ensuring Canonical has a great relationship
with our community.

I started and am still hosting the Ubuntu Security Podcast nearly every
week for the last 4 years as a way to evangelise the awesome work of the
Ubuntu Security team and the various security aspects of Ubuntu.

I am also involved with security aspects of snapd and as one of the snap
store reviewers to help guide snap publishers to make sure their snaps
can work as smoothly as possible for their users.

Finally, I've been a core-dev for a year and a half now as well.

I am really passionate about Ubuntu and helping to ensure that everyone
can benefit from it whilst also being as secure as possible in the
process.

One final aspect to mention here is that as an Australian, the current
team meeting time of the Tech Board (20:00 in London) is likely to be a
challenge for me for at least for half of the year once DST ends here +
starts in the UK. I realise that part of the criteria for
application/membership of the TB is to be able to make the existing
meeting time. However, I hope that if elected I could work with the
other TB members to try and find something that may work better for all
- whether alternating meeting times or shifting it during DST etc - so
that we can be inclusive for TB members no matter where in the world
they are located.

Thanks for your consideration, more than happy to answer any questions
anyone may have for me.

Cheers,
Alex


On Tue, 2022-11-29 at 19:07:26 +, Torsten Franz wrote:

> Hi everyone,
>
> We have received some applications for the new election of the Ubuntu 
> Technical Board. A lot of great applications from very good candidates. 
> In order to make a good decision in this selection, we would like to 
> give the candidates the opportunity to introduce themselves here and to 
> say a few words about their application and provide a few links to their 
> work. Everyone will also have the opportunity to ask the candidates 
> questions. We will start the election on 6 December. All five seats 
> (besides Mark) will be filled.
>
> Here is the list of candidates (by alphabetical order of surname):
>
> - Sebastien Bacher
> - Robie Basak
> - Ben Collins
> - Steve Langasek
> - Lukas Märdian
> - Alex Murray
> - Simon Quigley
> - Mathieu Trudel-Lapierre
> - Łukasz Zemczak
>
> If any questions arise, then the Ubuntu Community Council is available 
> to help.
>
> On behalf of the Ubuntu Community Council,
> Torsten Franz
>
>
> Am 22.11.2022 22:51 schrieb Merlijn Sebrechts:
>> WE ARE STILL LOOKING FOR CANDIDATES TO JOIN THE UBUNTU TECHNICAL
>> BOARD!
>> 
>> The call remains open until NOVEMBER 27TH, 2022, at 23:59 UTC. This is
>> a bit longer than initially anticipated.
>> 
>> Are you interested or do you know of someone who you want to see in
>> this role? Please submit the nomination.
>> 
>> WHAT IS THE UBUNTU TECHNICAL BOARD?
>> 
>> The Ubuntu Technical Board is responsible for the technical direction
>> of Ubuntu. It makes decisions on package selection, packaging policy,
>> installation systems and processes, kernel, X server, display
>> management, library versions, and dependencies. The board works with
>> relevant teams to establish a consensus on the right path to take,
>> especially where diverse elements of Ubuntu cannot find consensus on
>> shared components. The current Technical Board is expiring at the end
>> of the year, and the Community Council would like to confirm a new
>> Technical Board, consisting of five people, who will serve for two
>> years. The eligibility requirements are:
>> 
>> WHO IS ELIGIBLE?
>> 
>> Everyone who meets the following criteria:
>> 
>>  * Be an Ubuntu Core Developer
>>  * Be available during typical meeting hours [see
>> https://wiki.ubuntu.com/TechnicalBoardAgenda [1]]
>>  * Have insight into the Ubuntu Development process, architecture, and
>> technical culture
>> 
>> HOW DO YOU NOMINATE YOURSELF OR SOMEONE ELSE?
>> 
>> Send the Community Council an email (community-council AT
>> lists.ubuntu.com [2]). With your nomination. Note that you can
>> nominate yourself too!
>> 
>> HOW DOES THE ELECTION WORK?
>> 
>> The call remains open until November 27th, 2022, at 23:59 UTC. After
>> that, the Community Council will review the s

Re: Default DIR_MODE for Ubuntu

[Alex Murray]

On Thu, 2022-11-03 at 10:11:59 +, Benjamin Drung wrote:

> On Wed, 2022-11-02 at 18:15 +0100, Alex Murray wrote:
>> On Wed, 2022-11-02 at 15:23:08 +, Benjamin Drung wrote:
>> 
>> > Hi everyone,
>> > 
>> > adduser 3.123 (in Debian) changed the default mode for normal users
>> > (DIR_MODE) from 0755 to 0700. The default mode for system user
>> > (SYS_DIR_MODE) stayed untouched at 0755. See [1] and [2] for a
>> > reasoning.
>> > 
>> > Ubuntu on the other hand has been using mode 0750 for normal and system
>> > users for a long time.
>> > 
>> > I like to have the same default permissions on Debian and Ubuntu for
>> > consistency reasons. Can we adopt the default permission from Debian or
>> > should we start a discussion in Debian to change their DIR_MODE to
>> > 0750?
>> 
>> I don't see much of a tangible benefit to switching to DIR_MODE=0700 by
>> default in Ubuntu, however I would not oppose such a change - tighter
>> permissions generally sounds like a good thing, but I wonder if there
>> are other use-cases that this may break (and given that this is the
>> permission for the user's primary group I don't see that is has much of
>> a tangible difference as in general most users are not members of other
>> users' primary groups).
>
> I agree. Since users have their own primary group it makes more sense to
> have this users group have read access. So people can easily add users
> to other users groups to give them read access.
>
> I read through the mails on Debian and found no mentioning about 0750.
> So do you agree that I start a conversation in Debian for Debian change
> to 0750?
>

Yes, if you want to unify this between Debian and Ubuntu that would be
my preferred option.

>> Regarding SYS_DIR_MODE, I am not sure I fully understand the reasoning
>> for this remaining at 0755 - this doesn't seem to be specified in either
>> the NEWS or README. These seem to only say that there was a desire to
>> separate the two and have more restrictive permissions for regular users
>> without affecting system users, but there is no mention of particular
>> use-cases that would drive this decision.
>
> The SYS_DIR_MODE was introduced to have separate permission for normal
> and system users (to be able to only change normal user permission).
>
>> In the case of Ubuntu, I am not aware of any adverse impact of having
>> system users default to 0750 so my preference would be to maintain this,
>> but again I am interested to understand any good reasons why 0755 might
>> be preferred in this case.
>
> Since 0750 is tighter than 0755 and it obviously works for Ubuntu,
> Debian could switch to 0750 for SYS_DIR_MODE as well.

Sounds good to me :)

>
> -- 
> Benjamin Drung
> Debian & Ubuntu Developer
>
> -- 
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Default DIR_MODE for Ubuntu

[Alex Murray]

On Wed, 2022-11-02 at 15:23:08 +, Benjamin Drung wrote:

> Hi everyone,
>
> adduser 3.123 (in Debian) changed the default mode for normal users
> (DIR_MODE) from 0755 to 0700. The default mode for system user
> (SYS_DIR_MODE) stayed untouched at 0755. See [1] and [2] for a
> reasoning.
>
> Ubuntu on the other hand has been using mode 0750 for normal and system
> users for a long time.
>
> I like to have the same default permissions on Debian and Ubuntu for
> consistency reasons. Can we adopt the default permission from Debian or
> should we start a discussion in Debian to change their DIR_MODE to
> 0750?

I don't see much of a tangible benefit to switching to DIR_MODE=0700 by
default in Ubuntu, however I would not oppose such a change - tighter
permissions generally sounds like a good thing, but I wonder if there
are other use-cases that this may break (and given that this is the
permission for the user's primary group I don't see that is has much of
a tangible difference as in general most users are not members of other
users' primary groups).

Regarding SYS_DIR_MODE, I am not sure I fully understand the reasoning
for this remaining at 0755 - this doesn't seem to be specified in either
the NEWS or README. These seem to only say that there was a desire to
separate the two and have more restrictive permissions for regular users
without affecting system users, but there is no mention of particular
use-cases that would drive this decision.

In the case of Ubuntu, I am not aware of any adverse impact of having
system users default to 0750 so my preference would be to maintain this,
but again I am interested to understand any good reasons why 0755 might
be preferred in this case.

>
> [1] https://salsa.debian.org/debian/adduser/-/blob/master/debian/NEWS
> [2] "Default for DIR_MODE" on
> https://salsa.debian.org/debian/adduser/-/blob/master/debian/README
>
> -- 
> Benjamin Drung
> Debian & Ubuntu Developer
>
> -- 
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: rsync - security error

[Alex Murray]

On Fri, 2022-08-26 at 02:26:47 +, Thomas Ward wrote:

>
> Alex,
>
> I believe that OP is referring to the last set of CVEs listed here[1]
> announced on the 14th.  So forgive me while I poke the thread with
> additional information.    I think the original ask was about those.

No worries - thanks for the clarification 

>
> --
>
> CVE-2022-37434 was announced on the 14th.  And is patched already in Ubuntu 
> [2].
>
> CVE-2022-29154 is the second one, and was deemed too intrusive [3] to include 
> as a security update for any of the releases at the time of review (see the 
> details in the link).
>
>
>
> --
>
> Thomas
>
>
> [1]: https://rsync.samba.org/security.html
> [2]: https://ubuntu.com/security/CVE-2022-37434
> [3]: https://ubuntu.com/security/CVE-2022-29154
>
>
> ____
> From: Ubuntu-devel-discuss  on 
> behalf of Alex Murray 
> Sent: Thursday, August 25, 2022 9:52 PM
> To: mynek...@mail.de ; 
> ubuntu-devel-discuss@lists.ubuntu.com 
> Subject: Re: rsync - security error
>
> Hi
>
> In Ubuntu we generally do not upload new versions of packages once a
> particular Ubuntu release is made. Instead when a security bug (CVE) is
> announced, if the version of the particular package in that Ubuntu
> release is affected, the security team will backport the patch which
> fixes the bug to the older version of the package.
>
> As such, there are currently no known CVEs which have not been patched
> for rsync in Ubuntu - you can see this by looking at:
>
> https://ubuntu.com/security/cves?q==rsync===
>
> Thanks,
> Alex
>
> On Fri, 2022-08-19 at 21:05:42 +0200, mynek...@mail.de wrote:
>
>>
>> Hello,
>>
>> please provide a new version. The current one contains a security bug.
>>
>> The current one is 3.2.5.
>> See: https://rsync.samba.org/
>>
>> Thank you
>>
>> --
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss@lists.ubuntu.com
>> Modify settings or unsubscribe at: 
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: rsync - security error

[Alex Murray]

Hi

In Ubuntu we generally do not upload new versions of packages once a
particular Ubuntu release is made. Instead when a security bug (CVE) is
announced, if the version of the particular package in that Ubuntu
release is affected, the security team will backport the patch which
fixes the bug to the older version of the package.

As such, there are currently no known CVEs which have not been patched
for rsync in Ubuntu - you can see this by looking at:

https://ubuntu.com/security/cves?q==rsync===

Thanks,
Alex

On Fri, 2022-08-19 at 21:05:42 +0200, mynek...@mail.de wrote:

>
> Hello,
>
> please provide a new version. The current one contains a security bug.
>
> The current one is 3.2.5.
> See: https://rsync.samba.org/
>
> Thank you
>
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: quick question regarding rabbitmq-server 3.8 EOL and Ubuntu 20.04 LTS

[Alex Murray]

Hi Josh,

The Ubuntu Security team endeavours to support the various packages in
each Ubuntu release for the lifetime of the Ubuntu release itself,
regardless of corresponding upstream project's release / support cycles.

In this case, even though upstream RabbitMQ will be ending support for
rabbitmq 3.8 on 31 July 2022, the Ubuntu Security team will then instead
look to backport patches from the upstream 3.9 (or 3.10 etc) releases to
the 3.8.2 release as shipped in Ubuntu 20.04 LTS as required.

Thanks,
Alex

On Wed, 2022-07-13 at 21:36:50 +, Josh Drake wrote:

> Hi,
>
> I had a quick question regarding the rabbitmq-server package in Ubuntu 20.04 
> LTS.  For background context, a rabbitmq support company we contracted seemed 
> certain that rabbitmq-server was going end of life at the end of July (likely 
> based on the info at https://www.rabbitmq.com/versions.html), and seemed 
> pretty sure that this also meant it would no longer receive backported 
> security patches on Ubuntu 20.04 LTS even though it is a LTS release.
>
> This didn't sound right to me, so my question is: Will the Ubuntu 20.04 LTS 
> version of rabbitmq-server continue to receive backported security patches 
> throughout the lifetime of Ubuntu 20.04 LTS, even after RabbitMQ's extended 
> support for 3.8 ends at the July 2022?
>
> Thanks,
> Josh Drake
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: isc-dhcp: should we start phasing it out?

[Alex Murray]

On Mon, 2022-05-23 at 10:04:17 -0300, Andreas Hasenack wrote:

> Hi,
>
> On Mon, May 16, 2022 at 2:34 PM Andreas Hasenack  
> wrote:
>
>> Removing isc-dhcp would also allow us to reduce the need of old compat
>> src:bind9-libs package, probably even drop it.
>
> I just learned that upstream is now bundling the necessary bind9 libs
> into the upstream code:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942502#25
>
> Debian just did such an upload, in fact:
> https://tracker.debian.org/news/1323159/accepted-isc-dhcp-443-1-source-into-unstable/
>

Thanks for the heads-up Andreas - I have just captured this relationship
in the Ubuntu CVE tracker so that future bind9 CVEs will get flagged
against isc-dhcp as well.

> -- 
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ubuntu Error Tracker data retention

[Alex Murray]

On Mon, 2022-05-16 at 15:11:27 -0700, Brian Murray wrote:

> On Fri, May 13, 2022 at 10:29:30AM +0930, Alex Murray wrote:
>> On Thu, 2022-05-12 at 13:38:38 -0700, Brian Murray wrote:
>> 
>> > The Ubuntu Error Tracker receives crash reports from all releases of
>> > Ubuntu which are not out of standard support. These crash reports are
>> > then aggregated into buckets where some meta-information (package
>> > version and release of Ubuntu) about those crash reports is collected.
>> > The crash data in the Ubuntu Error Tracker is kept until the release
>> > reaches its end of standard support, however not all the data from each
>> > individual crash gets scrubbed and there is still some detailed
>> > information for crashes from releases as old as Ubuntu 12.04.
>> >
>> > I plan on changing this policy so that all the information from
>> > individual crash reports (basically what is in the .crash file) is
>> > removed when the release reaches its end of standard support. That would
>> > mean that all the information for crashes from Ubuntu 21.10 would be
>> > removed in July of 2022 and for Ubuntu 18.04 it would be removed in
>> > April of 2023. Keeping in mind that a crash bucket would still indicate
>> > that old release and package version were affected are there any
>> > objections to this change in data retention?
>> 
>> We are now supporting LTS releases for 5 additional years via ESM and so
>> from the security team's perspective 16.04 will be supported* until 2026
>> and 18.04 until 2028. I can imagine it would be useful to still have
>> error reports retained and collected for these releases during this ESM
>> period to help identify any possible regressions introduced via ESM
>> security updates.
>> 
>> So as a general rule, for the LTS releases can we please retain and
>> support them in the Ubuntu Error Tracker for 10 years?
>
> I don't think having an individual crash report from 2016 would be
> useful in 2021, let alone in 2026. How would the security team feel
> about keeping the individual crashes for a maximum of 5 years?

Oh that is a good point - indeed, 5 years for the individual crash
reports themselves sounds quite sufficient.

>
> --
> Brian Murray

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ubuntu Error Tracker data retention

[Alex Murray]

On Thu, 2022-05-12 at 13:38:38 -0700, Brian Murray wrote:

> The Ubuntu Error Tracker receives crash reports from all releases of
> Ubuntu which are not out of standard support. These crash reports are
> then aggregated into buckets where some meta-information (package
> version and release of Ubuntu) about those crash reports is collected.
> The crash data in the Ubuntu Error Tracker is kept until the release
> reaches its end of standard support, however not all the data from each
> individual crash gets scrubbed and there is still some detailed
> information for crashes from releases as old as Ubuntu 12.04.
>
> I plan on changing this policy so that all the information from
> individual crash reports (basically what is in the .crash file) is
> removed when the release reaches its end of standard support. That would
> mean that all the information for crashes from Ubuntu 21.10 would be
> removed in July of 2022 and for Ubuntu 18.04 it would be removed in
> April of 2023. Keeping in mind that a crash bucket would still indicate
> that old release and package version were affected are there any
> objections to this change in data retention?

We are now supporting LTS releases for 5 additional years via ESM and so
from the security team's perspective 16.04 will be supported* until 2026
and 18.04 until 2028. I can imagine it would be useful to still have
error reports retained and collected for these releases during this ESM
period to help identify any possible regressions introduced via ESM
security updates.

So as a general rule, for the LTS releases can we please retain and
support them in the Ubuntu Error Tracker for 10 years? Or alternatively
for a more flexible solution, just use the eol-esm date from
/usr/share/distro-info/ubuntu.csv in distro-info-data when it is present
otherwise fallback to the eol date (since the eol-esm column is only
populated for LTS releases from what I can see).

>
> Thanks,
> --
> Brian Murray
>
> -- 
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Missiing bacula-fd for 9.6.7-3 Ubuntu 2204

[Alex Murray]

On Tue, 2022-05-03 at 10:48:21 -0400, Ken Mandelberg wrote:

> All the other packages for bacula (director, sd) are available but not 
> bacula-fd. bacula cannot run without it.

It seems it was removed during the jammy development cycle as it failed
to build from source:
https://launchpad.net/ubuntu/+source/bacula/+publishinghistory

>
>
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: CVE-2022-0543 also applies to Ubuntu

[Alex Murray]

FYI - updates to remediate this for Ubuntu 20.04 LTS and Ubuntu 21.10
were published earlier via USN-5316-1

https://ubuntu.com/security/notices/USN-5316-1

Thanks,
Alex


On Mon, 2022-03-07 at 13:14:12 +1030, Alex Murray wrote:

> Hi Reginaldo,
>
> I am taking a look at this now for Ubuntu (note as redis is in universe
> it is community maintained but since this is a relatively trivial fix
> and you are planning to release a PoC exploit I have taken this on
> myself).
>
> Thanks,
> Alex
>
> On Thu, 2022-03-03 at 16:21:19 -0300, Reginaldo Silva wrote:
>
>> Sure thing
>>
>> Debian bug:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005787
>>
>> Debian DSA:
>> https://www.debian.org/security/2022/dsa-5081
>>
>> Cheers,
>>
>> Reginaldo
>> On Thu, Mar 3, 2022 at 15:00 Thomas Ward  wrote:
>>
>>> Is there a Debian or Ununtu bug for this?  For tracking purposes for a fix
>>> and such.
>>>
>>>
>>>
>>> Sent from my Galaxy
>>>
>>>
>>>
>>>  Original message 
>>> From: Reginaldo Silva 
>>> Date: 3/3/22 11:59 (GMT-05:00)
>>> To: ubuntu-devel-discuss@lists.ubuntu.com
>>> Subject: CVE-2022-0543 also applies to Ubuntu
>>>
>>> Hi, Ubuntu team.
>>>
>>> Back in January I discovered that there's a redis sandbox escape on Debian
>>> and Debian-derived distributions. It also affects Ubuntu. Please update
>>> from the Debian sources (it's a one-line patch to debian/rules). I plan to
>>> publish a blog post with a Proof of Concept exploit, but will give time for
>>> Ubuntu to release a fix first.
>>>
>>> https://lists.debian.org/debian-security-announce/2022/msg00048.html
>>>
>>> Best regards,
>>>
>>> Reginaldo
>>>
>> -- 
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss@lists.ubuntu.com
>> Modify settings or unsubscribe at: 
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: CVE-2022-0543 also applies to Ubuntu

[Alex Murray]

Hi Reginaldo,

I am taking a look at this now for Ubuntu (note as redis is in universe
it is community maintained but since this is a relatively trivial fix
and you are planning to release a PoC exploit I have taken this on
myself).

Thanks,
Alex

On Thu, 2022-03-03 at 16:21:19 -0300, Reginaldo Silva wrote:

> Sure thing
>
> Debian bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005787
>
> Debian DSA:
> https://www.debian.org/security/2022/dsa-5081
>
> Cheers,
>
> Reginaldo
> On Thu, Mar 3, 2022 at 15:00 Thomas Ward  wrote:
>
>> Is there a Debian or Ununtu bug for this?  For tracking purposes for a fix
>> and such.
>>
>>
>>
>> Sent from my Galaxy
>>
>>
>>
>>  Original message 
>> From: Reginaldo Silva 
>> Date: 3/3/22 11:59 (GMT-05:00)
>> To: ubuntu-devel-discuss@lists.ubuntu.com
>> Subject: CVE-2022-0543 also applies to Ubuntu
>>
>> Hi, Ubuntu team.
>>
>> Back in January I discovered that there's a redis sandbox escape on Debian
>> and Debian-derived distributions. It also affects Ubuntu. Please update
>> from the Debian sources (it's a one-line patch to debian/rules). I plan to
>> publish a blog post with a Proof of Concept exploit, but will give time for
>> Ubuntu to release a fix first.
>>
>> https://lists.debian.org/debian-security-announce/2022/msg00048.html
>>
>> Best regards,
>>
>> Reginaldo
>>
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: log4j rce patch

[Alex Murray]

Hi Jeff

On Fri, 2021-12-10 at 15:53:51 -0500, Jeffrey Walton wrote:

> Hi Everyone,
>
> Has Ubuntu pushed a patch for the log4j rce that was dropped earlier today?
>
> At work, we think we are seeing activity due to zero day. But I am not
> sure the servers are fully patched at the moment.
>
> Also see https://www.randori.com/blog/cve-2021-44228/

Please see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/Log4Shell for 
more details but updates are now available, however the USN is still pending 
publication.

>
> Jeff

Thanks,
Alex


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Ubuntu -fcf-protection=full breaking code

[Alex Murray]

On Tue, 2021-02-16 at 20:04:58 +1030, Matthias Klose wrote:


On 2/15/21 3:17 AM, Alex Murray wrote:

Hi Michael,

For Ubuntu we try and take an approach where we want as much code that
is compiled for and *on* Ubuntu to try and take advantage of the various
toolchain hardening options that are available.  This gives end-users
the most protection with the least amount of work.


Alex, this doesn't match my memory.  Turning on the hardening flags 
always was a
hack to build packages with hardening flags that ignored flags in their 
build

system, which are set by the packaging code.



I don't have the context for why the original decision was made back
when this was done the first time, but the above is my understanding and
rationale for why we continue to take this approach now. Also as state
below, in particular for effective cf-protection *everything* has to be
built with this enabled - are we sure this is do-able with the
buildflags or some other approach? I suspect we will always need this
kind of hack as you call it to ensure significant coverage is achieved
across the whole archive.


In some cases however, this can lead to issues as noted in the github
issue you linked to - not all compiler options will be suitable for all
codebases etc. However, there are a huge number of codebases which are
suitable for this kind of feature and automatically benefit from
this. Also as Ubuntu is used by a huge number of software developers and
is a platform of choice in CI/CD systems, this then allows many
codebases to automatically benefit from these default hardening
features. To make control-flow protection usable in practice, not only
does the binary need to be compiled with this enabled, but also all
shared libraries etc. If a user wants to compile a newer version of a
library, they can then simply do the usual, configure && make && make
install, and it will get compiled with these CFLAGS as well (whereas
were this done solely via dpkg-buildflags or similar, only
binaries/libraries shipped via debs would likely be compiled with this
feature which would then make it a bit pointless if some libraries have
it on but others do not).

So as with all things, there is a balance that needs to be struck
between the two - the current solution allows this default to be turned
off via CFLAGS as mentioned at
https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fcf-protection if
needed - but also ensures that as many different packages or bespoke
codebases will be compiled with this option on (and as such likely then
ensure it can be used in end-deployments as with any luck all dependent
libraries get compiled with it on as well).


The current "balance" is to force things into GCC first, and then tending 
to

ignore or delay any follow-up work.  -fcf-protection and
-fstack-clash-protection don't show up in build logs for package builds, 
so at
least for package builds, package maintainers don't easily see which 
hardening

flags are in use.


The omission of clang and other compilers is a good point and I agree we
should be trying to ensure we use the same default compiler flags for
all compilers which support them. At this stage however, the use of gcc
still outweighs other compilers significantly, probably not least
because build-essential depends on gcc not clang. But especially in
light of the want to have as full coverage of the archive as possible
for effective cf-protection, we should make it a priority to ensure
clang and others are supported as well.



Software built by other compilers doesn't take "advantage of the various
toolchain hardening options", so I think your claim made in the first 
paragraph

is at least misleading.


This is true but again I would say the usage of clang or other compilers
on Ubuntu is a lot smaller than gcc - so by targetting gcc with these
features we get the majority of users.


Non-package builds don't see any of these hardening
options, as well as packages ignoring options set in the build 
environment.
Even packages respecting their build environment don't see 
-fcf-protection and

-fstack-clash-protection at all.


Whilst you don't see these compiler flags in the build output, they are
still on - so these non-package builds etc still benefit from
them. There are also many other compiler flags which are implicitly
enabled but which don't get shown on the command-line or similar when
you compile things - should we be expecting to surface these as well?


Users are also happy using these compilers to
work around the Ubuntu GCC settings with the least amount of work.


I am confused - above you seem to suggest that the omission of these
flags from other compilers is something that should be addressed as a
current shortcoming - but this sentence seems to advocate for not doing
this as a workaround for the current default-on implementation.

I am more than happy to revisit how we implement the default compiler
options for enabling various toolchai

Re: Ubuntu -fcf-protection=full breaking code

[Alex Murray]

On Tue, 2021-02-16 at 20:04:58 +1030, Matthias Klose wrote:


On 2/15/21 3:17 AM, Alex Murray wrote:

Hi Michael,

For Ubuntu we try and take an approach where we want as much code that
is compiled for and *on* Ubuntu to try and take advantage of the various
toolchain hardening options that are available.  This gives end-users
the most protection with the least amount of work.


Alex, this doesn't match my memory.  Turning on the hardening flags 
always was a
hack to build packages with hardening flags that ignored flags in their 
build

system, which are set by the packaging code.



I don't have the context for why the original decision was made back
when this was done the first time, but the above is my understanding and
rationale for why we continue to take this approach now. Also as state
below, in particular for effective cf-protection *everything* has to be
built with this enabled - are we sure this is do-able with the
buildflags or some other approach? I suspect we will always need this
kind of hack as you call it to ensure significant coverage is achieved
across the whole archive.


In some cases however, this can lead to issues as noted in the github
issue you linked to - not all compiler options will be suitable for all
codebases etc. However, there are a huge number of codebases which are
suitable for this kind of feature and automatically benefit from
this. Also as Ubuntu is used by a huge number of software developers and
is a platform of choice in CI/CD systems, this then allows many
codebases to automatically benefit from these default hardening
features. To make control-flow protection usable in practice, not only
does the binary need to be compiled with this enabled, but also all
shared libraries etc. If a user wants to compile a newer version of a
library, they can then simply do the usual, configure && make && make
install, and it will get compiled with these CFLAGS as well (whereas
were this done solely via dpkg-buildflags or similar, only
binaries/libraries shipped via debs would likely be compiled with this
feature which would then make it a bit pointless if some libraries have
it on but others do not).

So as with all things, there is a balance that needs to be struck
between the two - the current solution allows this default to be turned
off via CFLAGS as mentioned at
https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fcf-protection if
needed - but also ensures that as many different packages or bespoke
codebases will be compiled with this option on (and as such likely then
ensure it can be used in end-deployments as with any luck all dependent
libraries get compiled with it on as well).


The current "balance" is to force things into GCC first, and then tending 
to

ignore or delay any follow-up work.  -fcf-protection and
-fstack-clash-protection don't show up in build logs for package builds, 
so at
least for package builds, package maintainers don't easily see which 
hardening

flags are in use.


The omission of clang and other compilers is a good point and I agree we
should be trying to ensure we use the same default compiler flags for
all compilers which support them. At this stage however, the use of gcc
still outweighs other compilers significantly, probably not least
because build-essential depends on gcc not clang. But especially in
light of the want to have as full coverage of the archive as possible
for effective cf-protection, we should make it a priority to ensure
clang and others are supported as well.



Software built by other compilers doesn't take "advantage of the various
toolchain hardening options", so I think your claim made in the first 
paragraph

is at least misleading.


This is true but again I would say the usage of clang or other compilers
on Ubuntu is a lot smaller than gcc - so by targetting gcc with these
features we get the majority of users.


Non-package builds don't see any of these hardening
options, as well as packages ignoring options set in the build 
environment.
Even packages respecting their build environment don't see 
-fcf-protection and

-fstack-clash-protection at all.


Whilst you don't see these compiler flags in the build output, they are
still on - so these non-package builds etc still benefit from
them. There are also many other compiler flags which are implicitly
enabled but which don't get shown on the command-line or similar when
you compile things - should we be expecting to surface these as well?


Users are also happy using these compilers to
work around the Ubuntu GCC settings with the least amount of work.


I am confused - above you seem to suggest that the omission of these
flags from other compilers is something that should be addressed as a
current shortcoming - but this sentence seems to advocate for not doing
this as a workaround for the current default-on implementation.

I am more than happy to revisit how we implement the default compiler
options for enabling various toolchai

Re: Ubuntu -fcf-protection=full breaking code

[Alex Murray]

Hi Michael,

For Ubuntu we try and take an approach where we want as much code that
is compiled for and *on* Ubuntu to try and take advantage of the various
toolchain hardening options that are available.  This gives end-users
the most protection with the least amount of work.

In some cases however, this can lead to issues as noted in the github
issue you linked to - not all compiler options will be suitable for all
codebases etc. However, there are a huge number of codebases which are
suitable for this kind of feature and automatically benefit from
this. Also as Ubuntu is used by a huge number of software developers and
is a platform of choice in CI/CD systems, this then allows many
codebases to automatically benefit from these default hardening
features. To make control-flow protection usable in practice, not only
does the binary need to be compiled with this enabled, but also all
shared libraries etc. If a user wants to compile a newer version of a
library, they can then simply do the usual, configure && make && make
install, and it will get compiled with these CFLAGS as well (whereas
were this done solely via dpkg-buildflags or similar, only
binaries/libraries shipped via debs would likely be compiled with this
feature which would then make it a bit pointless if some libraries have
it on but others do not).

So as with all things, there is a balance that needs to be struck
between the two - the current solution allows this default to be turned
off via CFLAGS as mentioned at
https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fcf-protection if
needed - but also ensures that as many different packages or bespoke
codebases will be compiled with this option on (and as such likely then
ensure it can be used in end-deployments as with any luck all dependent
libraries get compiled with it on as well).

Thanks,
Alex

On Tue, 2021-02-09 at 05:40:40 +1030, michael Bostwick wrote:


Any idea why
Overriding the default flags to include -fcf-protection=full breaks ipxe,
and other tooling not coded to work around it as can be seen on github:
https://github.com/ipxe/ipxe/commit/e8393c3728bf7073d033410373ef6781549c7c3e#commitcomment-46894324

There is an easier and more straightforward work around (preferred CFLAGS
within the package build), why not use that ?



--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fw: intel microcode package(>3.20191115) is not working with intel core i9

[Alex Murray]

Hi Dmitriy

Can you please file a bug via launchpad against the intel-microcode
package?

The easiest way to do this is to run the following command in a
terminal on a machine which is experiencing this issue:

ubuntu-bug intel-microcode

This will then collect various information about the hardware etc - then
we can follow up there.

For now, if this is preventing the machine from booting, please add the
dis_ucode_ldr boot parameter which should allow the machine to boot -
for information on how to do this please refer to
https://wiki.ubuntu.com/Kernel/KernelBootParameters

Thanks,
Alex

On Mon, 2021-01-11 at 11:18:09 +1030, Дмитрий wrote:


Please help

--
Best Regards
Dmitriy


--- Пересылаемое сообщение ---
От кого: "Дмитрий" 
Кому: h...@debian.org
Тема: intel microcode package(>3.20191115) is not working with intel core 
i9

Дата: 11 января 2021, 02:31:35

Hello

We have an issue with packages for ubuntu 
http://ftp.ubuntu.com/ubuntu/pool/main/i/intel-microcode/?C=M;O=A on 
intel core i9.  Currently is working package 
intel-microcode 3.20191115.1ubuntu3


Please see more details here - 
https://forums.linuxmint.com/viewtopic.php?f=90=264305=20 and 
https://forums.linuxmint.com/viewtopic.php?f=49=339625=1951691#p1951691


Please help due to many customers since 20.1 LTS will have black screen 
and it means at least we can loose some part of customers which is not 
"good in linux" (and not able to set grub option) and they are not able 
to manipulate with different intel-microcode packages.


Thanks in Advance

--
Best Regards
Dmitriy



--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fwd: Private home directories for hirsute onwards

[Alex Murray]

Just to follow up on this thread - since there was no opposition to this
proposal, I have uploaded updated adduser and shadow packages to
hirsute-proposed to support setting the mode of home directories to 750
by default when they are created via either adduser or useradd.

Let me know if you encounter any significant issues :)

On Mon, 2020-11-30 at 16:54:08 +1030, Robie Basak wrote:


Forwarding here in case there are Ubuntu developers who might want to
comment but don't read the ubuntu-devel-discuss@ list.

Since there's already a thread there, I suggest replying there if you
want to reply to avoid splitting the discussion.

There's also a cross-post to
https://discourse.ubuntu.com/t/private-home-directories-for-ubuntu-21-04-onwards/19533

HTH,

Robie

- Forwarded message from Alex Murray  
-


Date: Thu, 26 Nov 2020 13:00:52 +1030
From: Alex Murray 
To: ubuntu-devel-disc...@lists.ubuntu.com
Subject: Private home directories for hirsute onwards
User-agent: mu4e 1.4.13; emacs 28.0.50

Hi folks,

After more than 14 years[1] of debate, I propose that it is time we
moved ahead and stopped creating home directories as world-readable on
Ubuntu for hirsute onwards. The old arguments from the bug referenced in
[1] mainly centered on the convenience of this feature when considered
in regards to a shared desktop machine with multiple user accounts
wanting to easily share files with one-another. However, a lot of things
have changed in the last 14 years, not least of which that Ubuntu has a
significant customer and user-base in the public cloud and server
space. For these users, there is generally 1 admin account and perhaps a
number of less privileged worker accounts, and so world-readable home
directories now present more like a footgun than a feature - in this
case, if a worker account is compromised, an attacker could now more
easily access sensitive data from the other worker accounts or the admin
account. Whilst the Ubuntu Security team does a great job of staying on
top of security updates and keeping the distro packages as secure as
possible, there will always be instances[2] where for whatever reason
machines are not kept up-to-date or weak passwords are used and so they
become compromised. We should therefore be taking an approach to limit
access in this unlikely event.

The other part of the past argument for this was that knowledgeable
users / sysadmins will be aware of this default and will change it if
they deem necessary. Whilst I am sure that we do have many knowledgeable
users, we have many more who simply are deploying Ubuntu to solve other
tasks - and I think it goes against the usability proposition of Ubuntu
in these cases to expect admins to make this change. Instead we can
ensure these deployments limit the chance for sensitive information to
be compromised by changing this default.

It should be noted too that from a regression point-of-view, changing
this default will also not affect any permissions on existing installs
(if it was perhaps decided to SRU this change back to older releases) or
on upgrades - only if new users are created will they then have these
more restrictive permissions. By making this change now, this also gives
3 development releases and 2 interim releases to work through any
unforseen issues etc before landing in an LTS release. Without some
widespread testing it is not possible to know in advance all of the
possible use-cases that have depended on this behaviour which may then
have issues so I feel now is the time to make such a change so we can
determine any appropriate work-arounds and associated documentation etc
as needed.

As such, for a concrete proposal, I suggest changing /etc/adduser.conf
to specify DIR_MODE=0750 instead of the current DIR_MODE=0755 - this
will ensure any users created via adduser have their home-directory
non-readable and non-executable by others.

In the case of useradd[3] (the low-level util) this is a bit trickier -
whilst the documentation suggests we can set HOME_MODE in
/etc/login.defs this does not appear to be respected and only if we set
say UMASK=027 in /etc/login.defs and then create a user
(useradd -m -d /home/test test) does the home dir have the expected
permissions. However, modifying the default umask has other consequences
so I am not suggesting we consider that at this point. So this will need
some more investigation, for now I would like to focus on adduser as
this is the documented approach for adding new Ubuntu users .

If you want to try this yourself, you can simply:


# ensure future users homes are safe
sudo sed -i s/DIR_MODE=0755/DIR_MODE=0750/ /etc/adduser.conf

# then get your own house in order
chmod 750 $HOME


In regards to things to watch out for, one use-case that I have come
across myself is libvirt VMs where the disk image is stored in your home
directory - these become unreadable now to the libvirt-qemu user and so
you can't launch these anymore  - however, there is a simple fix

Re: Private home directories for hirsute onwards

[Alex Murray]

Just to follow up on this thread - since there was no opposition to this
proposal, I have uploaded updated adduser and shadow packages to
hirsute-proposed to support setting the mode of home directories to 750
by default when they are created via either adduser or useradd.

Let me know if you encounter any significant issues :)

On Fri, 2020-11-27 at 16:40:48 +1030, Alex Murray wrote:


On Fri, 2020-11-27 at 03:39:36 +1030, Dimitri John Ledkov wrote:

On Thu, Nov 26, 2020 at 2:31 AM Alex Murray  
wrote:


setfacl -m u:libvirt-qemu:rx $HOME



Similar to above for qemu are there similar setfacl commands, would
something similar be also needed for:
- sshd user to access ~/.ssh/authorized_keys , or nothing needed
there?


There is nothing needed here, ssh with public key auth works fine with
750 $HOME - sshd runs as root so this is fine


- in GNOME making ~/Public public?


Also tested this and is fine - gnome-user-shame spawns apache2 running
as the target user to share via webdav so this also works


- giving access to ~/public_html for the www-data user?


This also needs the same ACL based approach:

setfacl -m u:www-data:rx $HOME



If yes, then what are the commands?

I like this approach of selective and explicit setfacl commands to
grant ACLs on per-usecase basis. This is inline with modern ways of
managing permissions.

--
Regards,

Dimitri.



--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Private home directories for hirsute onwards

[Alex Murray]

On Fri, 2020-11-27 at 03:39:36 +1030, Dimitri John Ledkov wrote:

> On Thu, Nov 26, 2020 at 2:31 AM Alex Murray  wrote:
>>
>> setfacl -m u:libvirt-qemu:rx $HOME
>>
>
> Similar to above for qemu are there similar setfacl commands, would
> something similar be also needed for:
> - sshd user to access ~/.ssh/authorized_keys , or nothing needed
> there?

There is nothing needed here, ssh with public key auth works fine with
750 $HOME - sshd runs as root so this is fine

> - in GNOME making ~/Public public?

Also tested this and is fine - gnome-user-shame spawns apache2 running
as the target user to share via webdav so this also works

> - giving access to ~/public_html for the www-data user?

This also needs the same ACL based approach:

setfacl -m u:www-data:rx $HOME

>
> If yes, then what are the commands?
>
> I like this approach of selective and explicit setfacl commands to
> grant ACLs on per-usecase basis. This is inline with modern ways of
> managing permissions.
>
> -- 
> Regards,
>
> Dimitri.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Private home directories for hirsute onwards

[Alex Murray]

Hi folks,

After more than 14 years[1] of debate, I propose that it is time we
moved ahead and stopped creating home directories as world-readable on
Ubuntu for hirsute onwards. The old arguments from the bug referenced in
[1] mainly centered on the convenience of this feature when considered
in regards to a shared desktop machine with multiple user accounts
wanting to easily share files with one-another. However, a lot of things
have changed in the last 14 years, not least of which that Ubuntu has a
significant customer and user-base in the public cloud and server
space. For these users, there is generally 1 admin account and perhaps a
number of less privileged worker accounts, and so world-readable home
directories now present more like a footgun than a feature - in this
case, if a worker account is compromised, an attacker could now more
easily access sensitive data from the other worker accounts or the admin
account. Whilst the Ubuntu Security team does a great job of staying on
top of security updates and keeping the distro packages as secure as
possible, there will always be instances[2] where for whatever reason
machines are not kept up-to-date or weak passwords are used and so they
become compromised. We should therefore be taking an approach to limit
access in this unlikely event.

The other part of the past argument for this was that knowledgeable
users / sysadmins will be aware of this default and will change it if
they deem necessary. Whilst I am sure that we do have many knowledgeable
users, we have many more who simply are deploying Ubuntu to solve other
tasks - and I think it goes against the usability proposition of Ubuntu
in these cases to expect admins to make this change. Instead we can
ensure these deployments limit the chance for sensitive information to
be compromised by changing this default.

It should be noted too that from a regression point-of-view, changing
this default will also not affect any permissions on existing installs
(if it was perhaps decided to SRU this change back to older releases) or
on upgrades - only if new users are created will they then have these
more restrictive permissions. By making this change now, this also gives
3 development releases and 2 interim releases to work through any
unforseen issues etc before landing in an LTS release. Without some
widespread testing it is not possible to know in advance all of the
possible use-cases that have depended on this behaviour which may then
have issues so I feel now is the time to make such a change so we can
determine any appropriate work-arounds and associated documentation etc
as needed.

As such, for a concrete proposal, I suggest changing /etc/adduser.conf
to specify DIR_MODE=0750 instead of the current DIR_MODE=0755 - this
will ensure any users created via adduser have their home-directory
non-readable and non-executable by others.

In the case of useradd[3] (the low-level util) this is a bit trickier -
whilst the documentation suggests we can set HOME_MODE in
/etc/login.defs this does not appear to be respected and only if we set
say UMASK=027 in /etc/login.defs and then create a user
(useradd -m -d /home/test test) does the home dir have the expected
permissions. However, modifying the default umask has other consequences
so I am not suggesting we consider that at this point. So this will need
some more investigation, for now I would like to focus on adduser as
this is the documented approach for adding new Ubuntu users .

If you want to try this yourself, you can simply:


# ensure future users homes are safe
sudo sed -i s/DIR_MODE=0755/DIR_MODE=0750/ /etc/adduser.conf

# then get your own house in order
chmod 750 $HOME


In regards to things to watch out for, one use-case that I have come
across myself is libvirt VMs where the disk image is stored in your home
directory - these become unreadable now to the libvirt-qemu user and so
you can't launch these anymore  - however, there is a simple fix for
this  - you can use an ACL entry to re-enable this access for just the
libvirt-qemu user:

setfacl -m u:libvirt-qemu:rx $HOME

(or you could just store your images under /var/lib/libvirt/images)

I suspect this ACL approach may be needed for other common use-cases but
like I said above this remains to be seen so any testing others could
give of this would be really appreciated in helping to decide whether to
try and proceed with this change.

Finally, if there is a strong case for deployments who rely on the
existing functionality (say universities etc) where having to manually
roll-back the setting on each machine install would be painful, we could
look at adding some functionality to the installer/preseed/whatnot to
create initial users etc with the old permissions.

Thanks for taking the time to read this - any constructive feedback is
welcome.

Thanks,
Alex



[1] https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734
[2] 

Re: Proposal: Enabling DMESG_RESTRICT for Groovy Onward

[Alex Murray]

On Thu, 2020-06-18 at 03:00:35 +0930, Marc Deslauriers wrote:

> On 2020-06-16 8:40 p.m., Matthew Ruffell wrote:
>> Hello!
>> 
>> I am proposing that we enable the CONFIG_SECURITY_DMESG_RESTRICT [1] feature 
>> by
>> default for Groovy onward.
>>

This sounds like a great (and long overdue) addition - thanks for
investigating this Matthew!

>> I wish to propose that we restrict /bin/dmesg to users within the 'adm' group
>> only, which will have little visible impact to end users, while closing the
>> final security gap currently enjoyed by unprivileged users on multiuser 
>> systems.
>> 
>> The kernel log buffer is a treasure trove of sensitive information, and we 
>> give
>> it out freely to anyone who asks for it. There have been substantial efforts
>> upstream to reduce and prevent kernel addresses from being leaked, and usage 
>> of
>> printk with '%p' have largely been removed. This is not enough, as if a 
>> system
>> has suffered an oops, it still outputs functions, their offsets and 
>> addresses,
>> and particularly, the contents of the stack, which usually contains kernel
>> addresses.
>> 
>> Exploit developers and attackers can leverage these information leaks to
>> get past KASLR, and they can use the kernel log buffer to get instant 
>> feedback
>> on their privilege escalation attacks, as failures will be shown as further 
>> oops
>> messages, which attackers can use to fix and tune their programs until
>> they work.
>> 
>> Currently, if I create a new, unprivileged user on a Focal system, they 
>> cannot
>> access /var/log/kern.log, /var/log/syslog or see system events in journalctl.
>> But yet, they are given free reign to the kernel log buffer.
>>
>> $ sudo adduser dave
>> $ su dave
>> $ groups
>> dave
>> $ cat /var/log/kern.log
>> cat: /var/log/kern.log: Permission denied
>> $ cat /var/log/syslog
>> cat: /var/log/syslog: Permission denied
>> $ journalctl
>> Hint: You are currently not seeing messages from other users and the system.
>>   Users in groups 'adm', 'systemd-journal' can see all messages.
>>   Pass -q to turn off this notice.
>> Jun 16 23:44:59 ubuntu systemd[2328]: Reached target Main User Target.
>> Jun 16 23:44:59 ubuntu systemd[2328]: Startup finished in 69ms.
>> $ dmesg
>> [0.00] Linux version 5.4.0-34-generic (buildd@lcy01-amd64-014)
>> (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #38-Ubuntu SMP Mon May 25 
>> 15:46:55
>> UTC 2020 (Ubuntu 5.4.0-34.38-generic 5.4.41)
>> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-34-generic
>> root=UUID=f9f909c3-782a-43c2-a59d-c789656b4188 ro
>> ...
>> 
>> Why should users have access to dmesg if they can't access /var/log/kern.log?
>> 
>> I propose that we restrict access to dmesg to users in group 'adm' like so:
>> 
>> 1) CONFIG_SECURITY_DMESG_RESTRICT=y in the kernel.
>> 2) Following changes to /bin/dmesg permissions in package 'util-linux'
>> - Ownership changes to root:adm
>> - Permissions changed to 0750 (-rwxr-x---)
>> - Add cap_syslog capability to binary.
>> 3) Add a commented out '# kernel.dmesg_restrict = 0' to
>>/etc/sysctl.d/10-kernel-hardening.conf

This sounds like a nice and effective way of achieving this - plus since
we now have journald and journalctl (used by gnome-logs and others) this
matches the behaviour seen there as well.

+1 from me!

>> 
>> For most users, they will use the initial admin account, which is in the 
>> 'adm'
>> group already, and will see no impact to these changes. If a log scraper type
>> program needs access to dmesg, the user the daemon runs as can simply be 
>> added
>> to the 'adm' group.
>> 
>> You can try the proposed changes at home, right now with:
>> 
>> 1) sudo chown root:adm /bin/dmesg
>> 2) sudo chmod 0750 /bin/dmesg
>> 3) sudo setcap cap_syslog=ep /bin/dmesg
>> 4) sudo sysctl -w kernel.dmesg_restrict=1
>> 
>> You admin user will be able to access dmesg like normal, and if you make a
>> unprivileged user, they will see:
>> 
>> $ dmesg
>> -bash: /usr/bin/dmesg: Permission denied
>> 
>> Let me know your thoughts and concerns.
>> 
>> Note: This is NOT an attempt to remove 'adm' from the default admin user.
>> Having access to 'adm' as the default user is what makes Ubuntu special and
>> easy to use, and I wouldn't want to place a breaking change like that on our
>> community.
>> 
>> Thanks,
>> Matthew Ruffell
>> Sustaining Engineering
>> 
>> [1] 
>> https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html#dmesg-restrict
>> 
>
>
> Some historical context:
>
> https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033240.html
>
> Marc.


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: apport permission error

[Alex Murray]

On Wed, 2020-03-04 at 03:49:39 +1030, Robie Basak wrote:

> On Tue, Feb 25, 2020 at 09:09:24AM -0800, Steve Langasek wrote:
>> Thanks, it's easy enough to back out later (as long as someone actually
>> raises a flag when things break!), so I'm ok with that.
>
> bacula's various postinsts (at least bacula-sd.postinst) fail with
> fs.protected_regular=2. This breaks at package install time, which is
> perhaps marginally worse than runtime. The fix is trivial though, and
> I'll be landing it soon.
>
> A rerun of the bacula autopkgtests following the fs.protected_regular
> change would have detected this case.
>
> I'm not sure we have enough data yet to make a final decision on
> fs.protected_regular=2 for Focal, but this is another data point.
>
> I'm not sure if it would be useful or not to rerun autopkgtests for the
> entire archive. There would certainly be a large amount of noise. It
> might be the case that maintainer scripts are more prone to this kind of
> thing because of their heavy use of shell and commonly mktemp. A survey
> of package maintainer scripts that use both mktemp and chown might be
> another analysis method. But of course they might source files from
> elsewhere, which would be non-trivial to follow.
>

Whilst it might not be feasible to rerun all of the autopkgtests for the
entire archive, I wonder whether perhaps just installing and removing
all* packages from the archive would be enough to find these corner
cases, particularly if they are most likely in postinst etc scripts?

> Here are details of the bacula case:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953030
> https://code.launchpad.net/~racb/ubuntu/+source/bacula/+git/bacula/+merge/380163

*install --reinstall for already installed packages and install followed
 by remove for ones which are not already installed on the given system
 under test

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Crash in Qt 5.12.2

[Alex Murray]

On Wed, 2019-10-23 at 21:51:27 +1030, Robert Loehning wrote:

> Am 23.10.19 um 09:29 schrieb Alex Murray:
>> 
>> On Wed, 2019-10-23 at 17:32:58 +1030, Robert Loehning wrote:
>> 
>>> Am 22.10.19 um 18:41 schrieb Dmitry Shachnev:
>>>> Hi again Robert,
>>>>
>>>> On Fri, Oct 18, 2019 at 02:14:01PM +, Robert Loehning wrote:
>>>>> Hi,
>>>>>
>>>>> every application based on Qt will crash when opening a crafted plain
>>>>> text file. Could you please add the patch below to your builds to fix 
>>>>> this?
>>>>>
>>>>> Thank you and have a nice weekend.
>>>>
>>>> Let me forward you a question I got on the bug:
>>>>
>>>> https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1848784/comments/1
>>>>
>>>>   This would appear to have security implications since I imagine if an 
>>>> email
>>>>   were sent to a KMail recipient which was crafted in this same way it 
>>>> would
>>>>   crash KMail? If this is likely true a CVE should be requested from MITRE 
>>>> via
>>>>   https://cveform.mitre.org/ so that other distros etc can ensure they ship
>>>>   this patch too.
>>>>
>>>> What do you think about this?
>>>>
>>>> --
>>>> Dmitry Shachnev
>>>>
>>>
>>> Hi Dmitry,
>>>
>>> this is most probably right. I expect that it's possible to crash KMail
>>> in that way. With Quassel, it was already used ITW.
>>>
>>> I don't think I'm authorized to send you such a crafted file, but if you
>>> look closely at the test for the attached fix, you can probably figure
>>> it out yourself.
>>>
>>> I'm not aware of an existing CVE for this issue, though.
>> 
>> FYI - I have just submitted a CVE application for this to MITRE so that
>> all distros can be notified of, and backport the fix as appropriate.
>
> Wonderful! Thank you so much!

MITRE have assigned CVE-2019-18281 for this issue.

>
> Cheers,
> Robert


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Crash in Qt 5.12.2

[Alex Murray]

On Wed, 2019-10-23 at 17:32:58 +1030, Robert Loehning wrote:

> Am 22.10.19 um 18:41 schrieb Dmitry Shachnev:
>> Hi again Robert,
>> 
>> On Fri, Oct 18, 2019 at 02:14:01PM +, Robert Loehning wrote:
>>> Hi,
>>>
>>> every application based on Qt will crash when opening a crafted plain
>>> text file. Could you please add the patch below to your builds to fix this?
>>>
>>> Thank you and have a nice weekend.
>> 
>> Let me forward you a question I got on the bug:
>> 
>> https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1848784/comments/1
>> 
>>   This would appear to have security implications since I imagine if an email
>>   were sent to a KMail recipient which was crafted in this same way it would
>>   crash KMail? If this is likely true a CVE should be requested from MITRE 
>> via
>>   https://cveform.mitre.org/ so that other distros etc can ensure they ship
>>   this patch too.
>> 
>> What do you think about this?
>> 
>> --
>> Dmitry Shachnev
>> 
>
> Hi Dmitry,
>
> this is most probably right. I expect that it's possible to crash KMail
> in that way. With Quassel, it was already used ITW.
>
> I don't think I'm authorized to send you such a crafted file, but if you
> look closely at the test for the attached fix, you can probably figure
> it out yourself.
>
> I'm not aware of an existing CVE for this issue, though.

FYI - I have just submitted a CVE application for this to MITRE so that
all distros can be notified of, and backport the fix as appropriate.

>
> Cheers,
> Robert


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

New gcc hardening defaults in eoan (-fstack-clash-protection + -fcf-protection)

[Alex Murray]

Hi,

The security and foundations teams have been working to enable a couple
new hardening options in GCC as default for eoan / 19.10. These are
-fstack-clash-protection and -fcf-protection.

-fstack-clash-protection causes GCC to instrument variable-length stack
allocations so that each page is probed at allocation time to turn
possible code-execution "stack clash" attacks (via jumping stack guard
pages) into just a segmentation fault / denial of
service. -fcf-protection adds support for Intel's control-flow
enforcement technology (CET) instructions (these require hardware
support but on older hardware which does not support these new
instructions these are just no-ops).

These are not enabled on all architectures, in particular
-fstack-clash-protection is not enabled on 32-bit ARM archs (as this is
buggy) and -fcf-protection is only enabled on x86 archs (amd64/i386/x32)
as this is only available on this hardware.

These options can be disabled by using -fno-stack-clash-protection and
-fcf-protection=none respectively in CFLAGS / CPPFLAGS as documented at
[1].

Results from a test rebuild with these new options enabled _and using
gcc-9_ is at [2] and help would be appreciated in fixing any build
failures.

Thanks in particular to Matthias (doko) on the Foundations team for his
help with this.

Cheers,
Alex


[1] https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fstack-clash-protection
[2] 
https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190614-eoan.html

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: how sudo handles $HOME

[Alex Murray]

On Wed, 2019-05-15 at 02:42:56 +0930, Dan Streetman wrote:

> in Ubuntu, sudo retains the calling user's $HOME
>
> this is different from upstream sudo as well as all other UNIXes and
> even the sudo documentation we provide.  Should we remove our custom
> patch that adds this behavior?

I would argue that our current behaviour provides a more usable default
(eg. running vim via sudo uses your own configuration so you don't have
to maintain a copy of it in /root) and in the case of a machine with
multiple sudo users, they all get to use their own configuration rather
than a single configuration under /root.

However, it does diverge from upstream and so for new users this creates
a surprising situation if they are used to and expect the upstream
behaviour - (see comments 6 and 7 in
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/760140) - plus it
seems we do not document this change in the man page and so we are
creating even more surprises for our users.

From a security point of view I do not see any advantage from either
behaviour, so it is really more a usability question IMO.

>
> for reference and more details on downsides of our current sudo behavior, see:
> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302
>
> Note that I have kind-of hijacked the bug, as I believe the issue is
> larger than the python-based example in that bug.
>
> Also as I commented in that bug, I do not recommend changing the
> behavior for existing releases.  But I do think we should change the
> behavior starting in Eoan and future releases.

I agree if this is changed we should not try and SRU it back.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss