[pkg-cryptsetup-devel] Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

[Guilhem Moulin]

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
>> me at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20210911/c28cb96d/attachment.sig>