On Fri, Feb 21, 2020 at 02:04:37PM -0800, Kees Cook wrote:
> On Thu, Feb 20, 2020 at 03:45:39AM +0000, Seth Arnold wrote:
> > I'm worried that turning this flag on for the first time in an LTS release
> > may be breaking too many expectations.
> > Adapting applications may be too much effort; because I don't know what
> > exactly apport is doing here it is hard to estimate how much effort it
> > will take to adapt it. Possibly the user-launched apport instances need
> > to create their own directory on launch. Possibly apport needs a
> > more invasive redesign.
> > [...]
> > Source code searching is not practical. The combination of working
> > with files in a world-writable sticky directory and not already using
> > O_EXCL with O_CREAT is not feasible to search for.
> FWIW, I think that the scope of the change is small enough (only in
> world-writable stick directories) and dramatic enough (usually total
> failure), that the risk is worth the benefit. Excepting the very few
> special directories (like /var/crash, where the software using them
> is likely enumerable), I would also argue that breaking stuff in
> "standard" temp directories (like /tmp) that isn't using O_EXCL is
> actually _desirable_, given that it is expressly risky to operate in
> that condition.
> And, I would suggest that doing this in an LTS is the right thing to do,
> otherwise you wait 2 years before gaining this defense that would be
> actively _disabled_ compared to all other distros with a modern version
> of systemd. And if this is the first noticed problem, that seems to be a
> reasonably good indication of how rare the case is of it creating "real"
> problems.
As an additional wrinkle, procps in focal-proposed is now setting
fs.protected_regular=2 by default, overriding the systemd setting. This
hasn't made it out of proposed yet because the additional restriction broke
the postgresql-common autopkgtest (fix for this is in progress):
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1864423
Kees, it sounds like you were advocating for setting the level to
fs.protected_regular=1, but NOT raising it to 2. Should we back out this
procps change for 20.04?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Monday, 24 February 2020
Friday, 21 February 2020
Re: apport permission error
On Thu, Feb 20, 2020 at 03:45:39AM +0000, Seth Arnold wrote:
> I'm worried that turning this flag on for the first time in an LTS release
> may be breaking too many expectations.
>
> Adapting applications may be too much effort; because I don't know what
> exactly apport is doing here it is hard to estimate how much effort it
> will take to adapt it. Possibly the user-launched apport instances need
> to create their own directory on launch. Possibly apport needs a
> more invasive redesign.
> [...]
> Source code searching is not practical. The combination of working
> with files in a world-writable sticky directory and not already using
> O_EXCL with O_CREAT is not feasible to search for.
> I'm worried that turning this flag on for the first time in an LTS release
> may be breaking too many expectations.
>
> Adapting applications may be too much effort; because I don't know what
> exactly apport is doing here it is hard to estimate how much effort it
> will take to adapt it. Possibly the user-launched apport instances need
> to create their own directory on launch. Possibly apport needs a
> more invasive redesign.
> [...]
> Source code searching is not practical. The combination of working
> with files in a world-writable sticky directory and not already using
> O_EXCL with O_CREAT is not feasible to search for.
FWIW, I think that the scope of the change is small enough (only in
world-writable stick directories) and dramatic enough (usually total
failure), that the risk is worth the benefit. Excepting the very few
special directories (like /var/crash, where the software using them
is likely enumerable), I would also argue that breaking stuff in
"standard" temp directories (like /tmp) that isn't using O_EXCL is
actually _desirable_, given that it is expressly risky to operate in
that condition.
And, I would suggest that doing this in an LTS is the right thing to do,
otherwise you wait 2 years before gaining this defense that would be
actively _disabled_ compared to all other distros with a modern version
of systemd. And if this is the first noticed problem, that seems to be a
reasonably good indication of how rare the case is of it creating "real"
problems.
--
Kees Cook
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Fwd: Call for votes: Developer Membership Board restaffing
Let's try again with text...
On February 19, 2020 7:34:27 AM CST, Dan Streetman <dan.streetman@canonical.com> wrote:
<Snip/>
>
>On Fri, Feb 14, 2020 at 9:38 AM Robie Basak <robie.basak@ubuntu.com>
>wrote:
>>
>> The Developer Membership Board (DMB) has started a restaffing vote
>for
>> the seven members whose terms are expiring. The DMB is responsible
>for
>> reviewing and approving new Ubuntu developers. It evaluates
>prospective
>> Ubuntu developers and decides when to entrust them with developer
>> privileges. There are eight candidates:
>>
>> Łukasz Zemczak (sil2100)
>> Dan Streetman (ddstreet)
>> Simon Quigley (tsimonq2)
>> Thomas Ward (teward)
>> Eric Desrochers (slashd)
>> Micah Gersten (micahg)
>
>Hello @micahg, and thank you for your service on the DMB for all these
>years (since 2011)!
>
>However, I can't help but take note that even though you are a DMB
>member, you did not attend a single DMB meeting in 2019. Since quorum
>has been a serious problem for the DMB, could you please provide some
>insight about why you want to remain on the board, and what your
>thoughts are about improving meeting attendance in the future?
>
>Thanks!
I originally wasn't going to remain on the board for this reason since I've had schedule conflicts. However, I would like to try to ensure that there is a functioning board, so I submitted my name to insure there was a vote. I remember showing up for at least one meeting at the end of the year with no quorum or agenda. In that case there was no meeting and no roll call.
Anyways, I do intend to try to make at least one meeting per month.
Thanks,
Micah
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Wednesday, 19 February 2020
Re: apport permission error
On Fri, Feb 14, 2020 at 09:31:55AM -0300, Thadeu Lima de Souza Cascardo wrote:
> > > > It's worth noting whoopsie-upload-all is run as root. I've discovered
> > > > that changing /proc/sys/fs/protected_regular from 1 to 0 allows
> > > > whoopsie-upload-all to write to the file. I imagine that apport is not
> > > > the only application affected by this setting.
> > > >
> > > > What is the practical benefit of having protected_regular set to 1?
The Ubuntu Security Team would like to have these exploit mitigations
enabled if we can.
Application authors have been forgetting to add O_EXCL to their
open(O_CREAT) calls for decades; leaving it off is almost always a
mistake. protected_regular helps protect against a common exploit
mechanism.
However, among the systems I have easy access to, it appears
protected_regular wasn't enabled until focal[1].
I'm worried that turning this flag on for the first time in an LTS release
may be breaking too many expectations.
Adapting applications may be too much effort; because I don't know what
exactly apport is doing here it is hard to estimate how much effort it
will take to adapt it. Possibly the user-launched apport instances need
to create their own directory on launch. Possibly apport needs a
more invasive redesign.
> > Is there a system in place for tracking the number of breaks / programs
> > that have needed to adapt? As a follow on is there some way we could
> > search the archive for programs that will break because of this change?
Source code searching is not practical. The combination of working
with files in a world-writable sticky directory and not already using
O_EXCL with O_CREAT is not feasible to search for.
On failure, auditd will log entries that include "sticky_create_regular".
(I don't see any on my one focal system, but it is far from representative.)
> Any calls to fopen(..., "w") or fopen(..., "a") will use O_CREAT. But we are
> talking about opening a file for writing on /tmp/, where the usual pattern is
> using mktemp(3), then opening the file for writing. In this case, the file
> should not exist, and note that using mktemp is not advised, because of the
> races entailed. mkstemp is the recommended solution, where O_EXCL is also used.
This is an excellent demonstration of the problem; often times
applications are using an abstraction layer that prevents easily adding
O_EXCL to the open(2) call.
> Now, once files are created there, they can be read from, moved, but not opened
> for writing anymore, as lots of programs will end up using O_CREAT. Now, I
> can't answer if this is a pattern or not. You found one that is used for
> /var/crash/. Now, should /var/crash/ be world-writable? What does write there?
Debian Code Search suggests it's used without specific purpose:
https://codesearch.debian.net/search?q=%2Fvar%2Fcrash&perpkg=1
Apport, kernel crash dumps configured via the makedumpfile package, a tool
to clean up home directories, Intel openpath fabric tools, systemtap,
cockpit.
Interestingly enough, systemd-coredump(8) will write to
/var/lib/systemd/coredump instead of /var/crash.
> It has been like this since November. Though eoan would have been a better way
> to introduce it and see what breaks. As for the other options, at first, I
> would lean towards enabling them, but for regular files, it seems to be
> something that demands more thought.
Yes, eoan would have been the better time to enable this.
What will we use to determine when to enable this mitigation by default in
Ubuntu? We cannot expect all software to be adapted -- afterall, if all
software were adapted, then we would no longer need the mitigation. This
mitigation exists because a lot of software is potentially unsafe.
Addressing apport is probably part of the minimum. (I also wonder if we
could use systemd-coredump(8) to replace some of the more bug-prone
portions of apport.)
A Galera tool was recently fixed for protected_regular:
https://jira.mariadb.org/browse/MDEV-21140
Is there a third example of an application which trips over this
mitigation in a common usage?
Thanks again for bringing this up. We want this mitigation but if the
ecosystem is plainly not ready for it yet, we'd probably do more harm to
roll it out prematurely.
Thanks
[1]:
16.04 LTS:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:0
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:0
/proc/sys/fs/protected_symlinks:1
18.04 LTS:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:0
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:0
/proc/sys/fs/protected_symlinks:1
19.10:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:0
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:0
/proc/sys/fs/protected_symlinks:1
focal:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:1
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:1
/proc/sys/fs/protected_symlinks:1
> > > > It's worth noting whoopsie-upload-all is run as root. I've discovered
> > > > that changing /proc/sys/fs/protected_regular from 1 to 0 allows
> > > > whoopsie-upload-all to write to the file. I imagine that apport is not
> > > > the only application affected by this setting.
> > > >
> > > > What is the practical benefit of having protected_regular set to 1?
The Ubuntu Security Team would like to have these exploit mitigations
enabled if we can.
Application authors have been forgetting to add O_EXCL to their
open(O_CREAT) calls for decades; leaving it off is almost always a
mistake. protected_regular helps protect against a common exploit
mechanism.
However, among the systems I have easy access to, it appears
protected_regular wasn't enabled until focal[1].
I'm worried that turning this flag on for the first time in an LTS release
may be breaking too many expectations.
Adapting applications may be too much effort; because I don't know what
exactly apport is doing here it is hard to estimate how much effort it
will take to adapt it. Possibly the user-launched apport instances need
to create their own directory on launch. Possibly apport needs a
more invasive redesign.
> > Is there a system in place for tracking the number of breaks / programs
> > that have needed to adapt? As a follow on is there some way we could
> > search the archive for programs that will break because of this change?
Source code searching is not practical. The combination of working
with files in a world-writable sticky directory and not already using
O_EXCL with O_CREAT is not feasible to search for.
On failure, auditd will log entries that include "sticky_create_regular".
(I don't see any on my one focal system, but it is far from representative.)
> Any calls to fopen(..., "w") or fopen(..., "a") will use O_CREAT. But we are
> talking about opening a file for writing on /tmp/, where the usual pattern is
> using mktemp(3), then opening the file for writing. In this case, the file
> should not exist, and note that using mktemp is not advised, because of the
> races entailed. mkstemp is the recommended solution, where O_EXCL is also used.
This is an excellent demonstration of the problem; often times
applications are using an abstraction layer that prevents easily adding
O_EXCL to the open(2) call.
> Now, once files are created there, they can be read from, moved, but not opened
> for writing anymore, as lots of programs will end up using O_CREAT. Now, I
> can't answer if this is a pattern or not. You found one that is used for
> /var/crash/. Now, should /var/crash/ be world-writable? What does write there?
Debian Code Search suggests it's used without specific purpose:
https://codesearch.debian.net/search?q=%2Fvar%2Fcrash&perpkg=1
Apport, kernel crash dumps configured via the makedumpfile package, a tool
to clean up home directories, Intel openpath fabric tools, systemtap,
cockpit.
Interestingly enough, systemd-coredump(8) will write to
/var/lib/systemd/coredump instead of /var/crash.
> It has been like this since November. Though eoan would have been a better way
> to introduce it and see what breaks. As for the other options, at first, I
> would lean towards enabling them, but for regular files, it seems to be
> something that demands more thought.
Yes, eoan would have been the better time to enable this.
What will we use to determine when to enable this mitigation by default in
Ubuntu? We cannot expect all software to be adapted -- afterall, if all
software were adapted, then we would no longer need the mitigation. This
mitigation exists because a lot of software is potentially unsafe.
Addressing apport is probably part of the minimum. (I also wonder if we
could use systemd-coredump(8) to replace some of the more bug-prone
portions of apport.)
A Galera tool was recently fixed for protected_regular:
https://jira.mariadb.org/browse/MDEV-21140
Is there a third example of an application which trips over this
mitigation in a common usage?
Thanks again for bringing this up. We want this mitigation but if the
ecosystem is plainly not ready for it yet, we'd probably do more harm to
roll it out prematurely.
Thanks
[1]:
16.04 LTS:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:0
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:0
/proc/sys/fs/protected_symlinks:1
18.04 LTS:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:0
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:0
/proc/sys/fs/protected_symlinks:1
19.10:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:0
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:0
/proc/sys/fs/protected_symlinks:1
focal:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:1
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:1
/proc/sys/fs/protected_symlinks:1
Fwd: Call for votes: Developer Membership Board restaffing
I noticed that my reply to ubuntu-devel-announce was rejected, so just
to make everyone aware of my reply to the announcement, I am
forwarding it to ubuntu-devel.
to make everyone aware of my reply to the announcement, I am
forwarding it to ubuntu-devel.
@rbasak, for future DMB elections, I suggest you cc the ubuntu-devel
list, so people have a chance to reply with questions for candidates.
---------- Forwarded message ---------
From: Dan Streetman <dan.streetman@canonical.com>
Date: Fri, Feb 14, 2020 at 9:52 AM
Subject: Re: Call for votes: Developer Membership Board restaffing
To: Robie Basak <robie.basak@ubuntu.com>
Cc: <ubuntu-devel-announce@lists.ubuntu.com>, devel-permissions
<devel-permissions@lists.ubuntu.com>
On Fri, Feb 14, 2020 at 9:38 AM Robie Basak <robie.basak@ubuntu.com> wrote:
>
> The Developer Membership Board (DMB) has started a restaffing vote for
> the seven members whose terms are expiring. The DMB is responsible for
> reviewing and approving new Ubuntu developers. It evaluates prospective
> Ubuntu developers and decides when to entrust them with developer
> privileges. There are eight candidates:
>
> Łukasz Zemczak (sil2100)
> Dan Streetman (ddstreet)
> Simon Quigley (tsimonq2)
> Thomas Ward (teward)
> Eric Desrochers (slashd)
> Micah Gersten (micahg)
Hello @micahg, and thank you for your service on the DMB for all these
years (since 2011)!
However, I can't help but take note that even though you are a DMB
member, you did not attend a single DMB meeting in 2019. Since quorum
has been a serious problem for the DMB, could you please provide some
insight about why you want to remain on the board, and what your
thoughts are about improving meeting attendance in the future?
Thanks!
> Rafael D. Tinoco (rafaeldtinico)
> Robie Basak (rbasak)
>
> The vote closes on 2020-02-21 at approximately 18:00 UTC.
>
> Ballots are being mailed to all members of ~ubuntu-dev who have a public
> email address visible in Launchpad or who have linked GPG keys that
> verify against their Launchpad accounts. If you are a member of
> ~ubuntu-dev and don't receive a ballot, please contact me privately.
>
> On behalf of the DMB,
> Robie Basak
> --
> Devel-permissions mailing list
> Devel-permissions@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/devel-permissions
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Tuesday, 18 February 2020
Re: Python2 removal for focal ...
Sorry for delaying that email.
Based on some discussions, we are going forward with the Python2 removal.
python-defaults now migrated to the release pocket and therefore removing
the binary packages
libpython-dbg libpython-dev libpython-stdlib
python python-dbg python-dev python-doc python-minimal
All dependencies to these packages have been removed in the release and proposed
pockets, and hopefully won't come back again. Further steps are:
- Remove outstanding references to these binary packages in the list of not
built from source list. This means any package having a build dependency on one
of the above packages will need a fix.
- Scan the binary packages in the release pocket for the use of the python
shebang, and fix those to use python2 instead of python. This will not include
shebangs used in examples shipped in /usr/share/doc (we didn't care about these
before, and we don't care about those now).
- After the next archive test rebuild, check for build failures caused by the
removal of the python shebang.
- Before release, add a binary package "python-is-python2-but-deprecated"
package shipping the /usr/bin/python symlink, and providing the python package.
This allows users to keep the python symlink on upgrade from earlier releases,
or to explicitly install it if needed for legacy requirements. It also allows
packages from PPAs or third-party sources to be installable.
*The "python-is-python2-but-deprecated" package must not be used in build
dependencies, dependencies and recommendations in the focal release.*
- Forward looking, we are adding a package python-is-python3, also providing
the python symlink, which is *not* installed by default in 20.04 LTS. In
follow-up releases and in 22.04 LTS the python symlink pointing to python3 will
be installed by default. *python-is-python3 must not be used in dependencies,
build dependencies and recommendations.*
- Document that setup in the release notes.
- 20.04 LTS will ship python2. Derivatives who cannot port some
applications are able to use python2 for the 20.04 LTS release.
Matthias
PS: Some packages had to be removed from the archive to get this
transition/removal done. Please file a bug report to get those re-added, and CC
me on this report, even if it's after feature freeze.
On 1/25/20 4:54 AM, Matthias Klose wrote:
> One more update, the unversioned python packages are now gone in focal. There
> will be some cleanup to do for NBS and build dependencies. A more complete
> follow-up will be sent next week.
>
> I removed a lot of packages from focal to get this done. Apologies if that
> affects any derivative. Please contact me on irc or via email to restore those
> package. However I don't have the resources to actively port these packages to
> Python3.
>
> Up to the Python 3.8 transition ...
>
> Matthias
>
> On 06.01.20 14:21, Matthias Klose wrote:
>> An update ... starting today, python-defaults in -proposed doesn't build the
>> binary packages
>>
>> libpython-dbg libpython-dev libpython-stdlib
>> python python-dbg python-dev python-doc python-minimal
>>
>> anymore, because we don't ship those packages anymore in focal. Python2 usage
>> should be removed, or python2 should be used explicitly, so change any of the
>> dependencies above to
>>
>> libpython2-dbg libpython2-dev libpython2-stdlib
>> python2 python2-dbg python2-dev python2-doc python2-minimal
>>
>> and change she shabang to python2 if you need to keep the Python2 packages.
>>
>> The python command will be reintroduced before release in a new package
>> python-pointing-to-python2.
>>
>> Matthias
>>
>>
>> On 11.11.19 01:24, Matthias Klose wrote:
>>> Enabling the syncs form unstable brang all the Python2 removal goodness to
>>> focal, however sometimes a little bit too much. Ubuntu has it's own debt in now
>>> ownerless packages which still depend on some Python2 module which is now
>>> removed in Debian.
>>>
>>> When looking at update_excuses.html, you will likely see many "valid candiates"
>>> for migration, however when looking at update_output.txt, you'll see which
>>> packages prevent migration to the release pocket.
>>>
>>> Please find attached a script to track the current diff between the Python2
>>> removal in unstable and focal, but keep in mind, that this script doesn't show
>>> the packages anymore, which are stuck in the proposed pocket.
>>>
>>> What to do for the Python2 removal?
>>>
>>> - Convert the packages to Python3, this is the preferred option,
>>> although if it's not done by now, how likely is the conversion?
>>>
>>> - Remove the package. Please file bug reports, documenting the
>>> check for reverse-dependencies.
>>>
>>> - If the package still needs to be kept in the archive, go the
>>> painful way, and maybe re-introduce all the just removed
>>> Python2 module packages. If this is a source package
>>> building both Python2 and Python3 modules, your are then
>>> committed to merge this continuously. Also keep in mind that
>>> upstreams are already dropping support for Python2. Then
>>> better build the Python2 modules from a separate source.
>>>
>>> If you decide to keep Python2 based packages, make sure that
>>> the package doesn't reference any of the python, python-dev,
>>> python-dbg, python-doc packages, and doesn't use the unversioned
>>> python binary. These should use python2, python2-dev,
>>> python2-dbg, python2-doc instead and use the python2 binary.
>>>
>>> There are about 3300 bugs filed in Debian, 1500 are already closed, plus the 350
>>> packages only available in focal. Please keep the focus on the packages which
>>> are not migrating, and on reducing the number of Ubuntu only packages.
>>>
>>> And please don't shoot the messenger, I hope I didn't ever upload an Ubuntu-only
>>> Python2 package myself ;)
>>>
>>> Matthias
>>>
>>> https://people.canonical.com/~ubuntu-archive/transitions/html/python2-rm.html
>>> https://wiki.debian.org/Python/2Removal
>>>
>>
>>
>
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Subscribe to:
Posts (Atom)