On Sat, 11 Sep 2021 at 20:26:57 +0200, Christoph Anton Mitterer wrote: > On Sat, 2021-09-11 at 20:06 +0200, Guilhem Moulin wrote: >> So either I misremembered testing >> this at the time, or something changed meanwhile :-) I'd argue that >> ‘\’ >> is a special character which per documentation “needs to be escaped >> using octal sequences”, so both ‘\n’ and ‘\xHH’ yield unspecified >> behavior, but I guess that can be made explicit. > > Maybe the easiest is simply to write e.g.: > Every field of crypttab is unescaped using printf(1)’s “%b” conversion > specification, which unescapes the \-escapes (\n, \t, \0num, etc.) as > provided by the echo utility. > > Than we're always automatically on the safe side.
The use of `printf %b` to decode escape sequences is an internal implementation detail; documenting it would tie our hands for implementation changes… Also there is no guaranty that /bin/sh is dash; don't forget that we also run at initramfs stage where /bin/sh is typically `busybox ash` (but again no guaranty, it can be dash, bash, klibc's sh, or anything else) for which `printf %b` *does* decode \xHH. In my view overspecifying is all but ideal here. >> We assume that unprivileged users do not have write access to >> /etc/crypttab (actually, $TABFILE), keyscripts, or initramfs hook/ >> scripts. Otherwise one can replace askpass with `mail >> m...@example.net`, >> append ‘keyscript=gimme_your_password’ to crypttab entries, or simply >> ship compromised executables in the initramfs image. > > I'd still suggest to document that (and not just assume it silently)... > otherwise some smartypants admins might thinkt it's ok to allow users > to just append entries to crypttab in some way they think it would be > secure. Do we warn users not to make /usr/bin, /root or /etc/ld.so.conf writable by unprivileged users? :-) Or not to remove the sticky bit on /tmp? -- Guilhem.
signature.asc
Description: PGP signature
