Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users
hello!
On Thu, Mar 25, 2010 at 07:18:46PM +0100, debian@x.ray.net wrote:
> well actually i checked man initramfs-tools. i think if the
> explanation "/etc/initramfs-tools -> local admin config overriding
> package defaults, /usr/share/initramfs-tools -> package defaults" were
> in this manpage, too, that would have helped against people like me
> not getting it. :)
taking patches ;)
latest git is on
http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary
> > what you could help at is audit scripts in
> > /usr/share/initramfs-tools/conf.d/
> > and check that they don't set an mkinitramfs variable.
> > then the call in mkinitramfs to source them could be finaly droped.
>
> hm. i just know about uswsusp dropping a file there, setting
> KEYMAP=y
> which is a variable that is used by a hook script on initramfs
> creation - but i'm not sure that it doesn't also make sense during
> initramfs boot... i'll try to investigate and take care of this (as
> long as nobody tells me that i'm totally wrong here :).
indeed that one should move please file wishlist bug against uswsusp
indicating that this transition is wanted by mkinitramfs.
KEYMAP is a build variable for adding keymaps to initramfs.
don't understand why uswsusp would need that?
for cryptsetup it makes sense, but this seems a bit questionable.
> > concerning templating this is what each perl module likes to reinvent
> > badly, don't think we need that complexity.
>
> hm. i'm not sure i meant the same thing as you with 'template'. :)
> what i meant:
>
> currently when creating an initramfs - let's say under /tmp/foobar/ -
> files like /usr/share/initramfs-tools/scripts/local-top/lvm are copied
> to e.g. /tmp/foobar/scripts/local-top/lvm, and
> /etc/initramfs-tools/modules to e.g. /tmp/foobar/etc/modules and so
> on. i.e. on a mkinitramfs run, what i call 'template' is created from
> various sources (which mkinitramfs has to know about) and the
> 'template' then ends up as e.g. /tmp/foobar/.
>
> what i meant was: when these files, which are 'collected', already
> reside in /etc/initramfs-tools/template/ (e.g.
> /etc/initramfs-tools/template/scripts/...,
> /etc/initramfs-tools/template/modules, and so on), this would be less
> complex and more flexible, in so far as a mkinitramfs run would start
> with something like cp -a /etc/initramfs-tools/template/ /tmp/foobar/
> , the structure i.e. where a file actually ends up in the initramfs
> would be implicitly clear, and changes there (like a new tree
> necessary for and put there by some other package) would not need
> explicit support by or changes to mkinitramfs or a hook script.
this looks like trouble you could get easily file conflicts and stuff.
what be more neat is to have the initramfs of linux-2.6 the modules
build on build time and just concatenated with the staff that is
going on on your box, should reduce build time a lot too.
this something for squeeze +1
> (this is btw not a try to convince you of this idea - it's just to
> make sure you really know what i meant so you can decide on the real
> idea and not on a misunderstanding :)
thanks.
> >> and to answer my initial question, i guess using conf.d/ for
> >> modularized configs done by other packages is a good idea. :)
> >
> > depends what for if it's for bootvariables then it is fine and good.
> > for mkinitramfs i'd be happy to drop.
> [...]
> > seems good in general, just the packaging change can be dropped.
>
> ok, i just added the patch without the part moving the config to /etc,
> i.e. the 2nd chunk, just leaving the UMASK config, just for gerrit's
> convenience...
acked-by me :)
> regards,
>
> Chris
> diff -pruN ../a/dropbear-0.52/debian/initramfs/dropbear-conf ./dropbear-0.52/debian/initramfs/dropbear-conf
> --- ../a/dropbear-0.52/debian/initramfs/dropbear-conf 2010-03-25 11:42:21.000000000 +0100
> +++ ./dropbear-0.52/debian/initramfs/dropbear-conf 2010-03-25 11:48:38.000000000 +0100
> @@ -6,3 +6,12 @@
> #
>
> #DROPBEAR=y
> +
> +#
> +# UMASK: [ 4-DIGIT OCTAL UMASK ]
> +#
> +# umask to use when creating an initramfs
> +#
> +
> +UMASK=0077
> +
Reply to: