Hi Anton, Thanks for the feedback. You raise some valid concerns here.
I may have overlooked a simpler solution to the reproducibility problem I mentioned. I was wondering if we could copy the temporary file to /etc/console-setup with a constant name (in [1]). This does not tweak anything related to the temp file creation itself (either in /tmp or /run) but just rename the file when being copied to /etc/console-setup. Since the /etc/console-setup is for anything related to the console-setup package, I feel it may be safe to assume that any other application / program would not create a file with the same name as we would use. Would like to understand if I am overlooking something here? [1] https://salsa.debian.org/installer-team/console-setup/-/blob/master/setupcon?ref_type=heads#L1258 ________________________________________ From: Anton Zinoviev <[email protected]> Sent: Friday, January 31, 2025 4:42 PM To: balakumar adithya(ＴＳＩＰ TEUR); [email protected] Cc: dinesh kumar(ＴＳＩＰ TMIEC ODG Porting); kunijadar shivanand(ＴＳＩＰ TMIEC ODG Porting); ashrith sai(ＴＳＩＰ); hayashi kazuhiro(林 和宏 ＤＭＥ ○ＤＩＧ□ＭＰＳ○ＭＰ４); yoshida toshiko(吉田 敏子 ○ＤＩＴＣ□ＤＩＴ○ＯＳＴ) Subject: Re: Bug#977877: console-setup: setupcon --setup-dir ... generates temporary file name inside etc/console-setup directory On Fri, Jan 31, 2025 at 09:03:26AM +0000, [email protected] wrote: > > > > This temporary file name changes across builds which causes > > reproducibility issues. All file names in /tmp have to be unpredictable or else this leads to serious security problems. > I am attaching a patch that attempts to fix the issue mentioned here. > The attached patch attempts to solve this with a consistent suffix > appended to the temporary filename. There are at least two problems in this patch. First, what if something has already created a file /tmp/tmpkbd.kbdfile or /tmp/tmpkbd.kbd_linux or /tmp/tmpkbd.setupdir? Setupcon will fail. Anything can make such a file. This can be a previous failed for some reason run of setupcon, an user testing a new version of setupcon, a user who intentionaly does a DOS attack. Second, after you touch the temp file, it is imperative that you test that the touched file is owned by the user executing the script and that it is not a symlink. Otherwise, this can easily lead to the so called symlink attack. These are two problems that I can see. But even if these problems are fixed, I would still feel uneasy about the patch. In the area of security the people never say "the program runs ok in most environments, so it is ok to release it". In the area of security the people don't care whether the program runs ok or not. They care that the program is safe even in the worst possible UNTHINKABLE environment. The bottomline is that using "touch" to create a file in /run (with some appropriate checks) is probably safe. If this fails, you can probably try to create a file in in the home directory of the user running the script (although this would be unmannerly behaviour). However, if you have to create a file in /tmp, then this file has to be created using "mktemp". Anton Zinoviev
