Comment 8 for bug 1453900

With the fixes in bug 1452239 apport drops its privileges more properly and thus it cannot actually write core dumps into directories not writable by the user. This foils this attach already. However, I still want to make this more robust, manipulating the written core dump is still evil.

> 1. Remove the partial privilege drop.

I would still like to keep this. This will do all the file system operations as the user, not root.

> 2. Save the uid of the pid at the beginning, do not rely on the pid more than once since the actual process can change during the course of execution.

Agreed.

> 3. Drop privileges completely as soon as possible.

It has always meant to do that, except that it does it wrongly in the current code. This got fixed in bug 1452239.

> 4. Make sure the report files are actual files and not FIFOs.

Any kind of stat() test sounds like a TOCTOU race. Non-ancient versions already open the report file the proper way with os.O_WRONLY | os.O_CREAT | os.O_EXCL which should be proof against race conditions, symlink attacks, and other pre-existing files. The thing I want/need to fix is to avoid closing and reopening it for the core dump -- instead I'll use O_RDWR, keep the fd open, and read the core dump from the written file. Then other processes can mess around with the directory entries all they want.

Thanks for discovering this! This is quite a clever attack.