apport permission error

Seth Arnold seth.arnold at canonical.com
Thu Feb 20 03:45:39 UTC 2020


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20200220/4d8e15f1/attachment-0001.sig>


More information about the kernel-team mailing list