apport permission error

[Alex Murray]

On Tue, 2020-02-25 at 02:42:58 +1030, Steve Langasek wrote:

> 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?

(I'll let Kees respond for himself but figured this was a good point to
reply)

>From the Ubuntu Security team's view, it is not clear how much breakage
will result from setting this to 2 - setting protected_regular=1 is
already a good win and so far has seen little fallout that I know of
(Apport has already worked around this), but given how close we are to
FF I am a bit hesitant to mandate for this to be =2 (given we
already have one known failure as a result). From a security point of
view, =2 is a better default but this is not the only view that
matters.

So my preference would be to keep this at =2 for now but be confident
that we can back it out to =1 in the event that we suddenly discover a
bunch more issues in the near term.

>
> -- 
> 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 at ubuntu.com                                     vorlon at debian.org