Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users
hi!
maximilian attems wrote:
> quick answer /etc is for local admin /usr is for packages.
> first place overrides the later one.
> so your packaing change looks wrong to me.
>
> indeed some directories are only for mkinitramfs configuring
> others for boot time variables.
[...]
> your overview totaly confused me and partialy wrong let's start with
> important things, please checkout man initramfs-tools.
[...]
ic.
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. :)
> modules loading is a seperate story and is added
> in /usr/share/initramfs-tools/modules and corresponding file in /etc
...and /usr/share/initramfs-tools/modules.d/, ic.
> 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 :).
> 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 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 :)
>> 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...
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: