bootloader: initrd can be generated from the /tmp

[yarda]

This fixes regression introduced by 74c3d35. Also dropped redundant "error:" prefix from some related error messages.

[jmencak]

I can confirm this resolves the issue:

ERROR    tuned.plugins.plugin_bootloader: error: paths outside of the profile directories cannot be used: '/tmp/tmp.lXnl0Fc3mu'

when using the [bootloader] plug-in.

However, I wonder if this is not exposing Tuned to an attack from unprivileged users messing with the /tmp directory content and injecting their own content into the boot image thus causing privilege escalation. Have we considered this?

[yarda]

However, I wonder if this is not exposing Tuned to an attack from unprivileged users messing with the /tmp directory content and injecting their own content into the boot image thus causing privilege escalation. Have we considered this?

It shouldn't be a problem, it's creating the tmp content with the root ownership and mode 0755, so unprivileged users cannot alter the content and privileged user can already attack it different way without TuneD.

Regarding the race condition attack before the safe path check and chmod. The directory is not removed after the check and it is initially created with the mode 0700 by the mktemp tool. After the check the mode is loosen to the 0755. There is no opportunity for the attacker to change the content of the directory.

Regarding the symlink attack, it's using mktemp unpredictable random directory names, so for the attacker is nearly impossible to guess the name especially if she/he has very short window for the attack during the machine/TuneD startup. The /tmp is usually ramdisk. Even if the attacker would prepare millions of randomly generated symlinks in advance it will probably not fit the filesystem/ramdisk, so the exhaustive attack shouldn't be feasible here (the attacker will be probably stopped by the quota system). There is still very low probability that the attacker will have lucky guess, like winning the Eurojackpot, but IMHO it is already addressed in the mktemp utility which creates the directory atomically and if there is already existing name, it uses different name.

If the user uses the initrd_add_dir unsafe way it's her/his problem. We could mention it in the doc.

I could add one more safety checks to harden it even more if used unsafe way:

• add check to the initrd_add_dir option to check whether the target directory is owned by root and would fail if not. I am not sure whether this could cause more degraded states on OCP, e.g. in case TuneD wouldn't run under the root there.