Security information leak in internal qcow handler's check_config callback

[mgerstner]

The implementation of qcow_check_config presents an information leak, because it allows any user with access to the dbus system bus to check for the existance of files and directories, even if the user shouldn't have access to those files.

For example issuing this command as a regular user allows to get the knowledge, whether /root/.bash_history exists:

dbus-send --system --print-reply --dest=org.kernel.TCMUService1 /org/kernel/TCMUService1/qcow org.kernel.TCMUService1.CheckConfig string://root/.bash_history

These kind of information leaks in combination with other security issues often leverage more serious security issues.

I'd have suggested a bugfix for this but it is difficult to get right. If we knew the peer credentials from dbus we could do a comparison of those credentials against the target file credentials. This still would be difficult for corner cases, where the file itself would be accessible to the user, but not some of the upper components of the path.

The check_config callback does currently not provide a possibility to pass peer credential information in, so this would affect public API in some way. Also I've not found a simple way to get the dbus peer credentials via libgio, maybe by using a GDBusAuthObserver.

All quite complicated, might be easier to drop this config callback altogether.

[mikechristie]

We are actually in the process of removing the check_config callback, so just send a patch to remove them all (file_example.c will have a similar issue I think).

[mgerstner]

Okay I did as you suggested. Good hint with the file_example.c. It contains an even worse vulnerability, allows to temporarily create arbitrary files in the system, possibly deleting other processes' files after winning a race.

[mikechristie]

Patches for these were merged in PR above, so closing issue.