apport permission error

Brian Murray brian at canonical.com
Thu Feb 13 21:11:59 UTC 2020


On Thu, Feb 13, 2020 at 08:47:03AM -0300, Thadeu Lima de Souza Cascardo wrote:
> 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.

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?

Additionally, when did /proc/sys/fs/protected_regular get set to 1? I
ask as the crash in the Error Tracker shows systems running 19.10 being
affected but a physical machine and virtual machine I spot checked did
not have it set to 1.

Thanks!
--
Brian Murray



More information about the kernel-team mailing list