apport permission error

[Thadeu Lima de Souza Cascardo]

On Wed, Feb 12, 2020 at 03:43:28PM -0800, Brian Murray wrote:
> I've recently been investigating a bug[1] where whoopsie-upload-all,
> provided by apport, is unable to add extra details to crash reports.
> This happens when the crash report has the following attributes:
> 
> -rw-r----- 1 bdmurray whoopsie 194K Feb  7 15:22 _usr_bin_seeded-in-ubuntu.1000.crash
> 
> 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?
> 

This doesn't allow O_CREAT open on files inside world-writable sticky
directories.

So, basically, we are preventing the root running program to open a file
that is controlled by a potential attacker.

It seems open(filename, "ab") is what whoopsie-upload-all is calling that
python3 translates into:

openat(AT_FDCWD, "filename", O_WRONLY|O_CREAT|O_APPEND|O_CLOEXEC, 0666) = 3

I wonder if using "+b", then seeking would do what is intended here, as I
see no easy way to still use python's open and not use O_CREAT with "a" or
"w". I see there is os.open, which allows one to give the flags to be used:

os.open("filename", os.O_WRONLY | os.O_APPEND)

That would assume the file exists and fail otherwise, but it's better than
what is happening right now.

One could ask what could an attacker do with whoopsie-upload-all anyway
that it wouldn't be able to do with protected_regular = 1, but we are
protecting from a class of attacks, and other programs will need to adapt,
unfortunately, unless we start seeing so many breaks that we need to step
back.

Regards.
Cascardo.

> [1] http://launchpad.net/bugs/1848064
> 
> Thanks!
> --
> Brian Murray
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team