Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users
hi! maximilian attems wrote: 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 ok, patch attached, please feel free to correct/improve as necessary. hm. i just know about uswsusp dropping a file there, setting [...] indeed that one should move please file wishlist bug against uswsusp ok, will do that next. 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 sorry but i don't get that. regards, Chris diff --git a/initramfs-tools.8 b/initramfs-tools.8 index 55d413a..4998dbd 100644 --- a/initramfs-tools.8 +++ b/initramfs-tools.8 @@ -9,9 +9,13 @@ will be used during different phases of execution. Each of these will be discussed separately below with the help of an imaginary tool which performs a frobnication of a lvm partition prior to mounting the root partition. -Valid boot and hook scripts names consist solely of alphabetics, numerics +Valid boot and hook script names consist solely of alphabetics, numerics and underscores. Other scripts are discarded. +Where two directories exist for the same task, the one below +/usr/share/initramfs-tools/ is meant for scripts added by other packages, +while the one below /etc/initramfs-tools/ is meant for manually added scripts. + .SS Hook scripts These are used when an initramfs image is created and not included in the image itself. They can however cause files to be included in the image. diff --git a/mkinitramfs.8 b/mkinitramfs.8 index 5d3c42b..8f1fc7d 100644 --- a/mkinitramfs.8 +++ b/mkinitramfs.8 @@ -89,6 +89,7 @@ This option queries if mkinitramfs can create ramdisks for kernel version The default configuration file for the script. See .BR initramfs.conf (5) for a description of the available configuration parameter. +For configuration by other packages, files in /usr/share/initramfs-tools/conf-hooks.d/ will also be used for the same purpose. They will be sourced after initramfs.conf, thus settings from files from this directory will override settings from initramfs.conf. .TP .I /etc/initramfs-tools/modules @@ -96,12 +97,14 @@ Specified modules will be put in the generated image and loaded when the system .I /etc/modules, which is described in .BR modules (5). +For configuration by other packages, files in /usr/share/initramfs-tools/modules.d/ will additionally be used for the same purpose. .TP .I /etc/initramfs-tools/conf.d The conf.d directory allows to hardcode bootargs at initramfs build time via config snippets. This allows to set ROOT or RESUME. This is especially useful for bootloaders, which do not pass an root bootarg. +For (default) configuration by other packages, files in /usr/share/initramfs-tools/conf.d/ will also be used for the same purpose (files from /usr/share/initramfs-tools/conf.d/ will be ignored if a file with the same name exists in /etc/initramfs-tools/conf.d/). .TP .I /etc/initramfs-tools/DSDT.aml
Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users
hi! maximilian attems wrote: egrep UMASK /etc/initramfs-tools/initramfs.conf UMASK=0077 this was not yet documented in initramfs.conf.5, will be in next upload. ah ic. in this case i guess it were a good idea to automatically set UMASK=0077 in the initramfs config when installing dropbear. regarding initramfs-tools: when trying to locate the best[tm] place to put this, i first got a bit confused, and concluded with these findings regarding intramfs-tools in the end: /etc/initramfs-tools/conf.d/modularized 'initramfs.conf', i.e. used to configure mkinitramfs et al. /usr/share/initramfs-tools/conf-hooks.d/like /etc/initramfs-tools/conf.d/. /usr/share/initramfs-tools/conf.d/ copied to the initramfs into conf/, i.e. used to configure stuff when booting the initramfs. /etc/initramfs-tools/hooks/ hook scripts used to create initramfs. /usr/share/initramfs-tools/hooks/ like /etc/initramfs-tools/hooks/. /etc/initramfs-tools/scripts/ scripts used when booting the initramfs. /usr/share/initramfs-tools/scripts/ like /etc/initramfs-tools/scripts/. /usr/share/initramfs-tools/hooksconf.d/ unused? /etc/initramfs-tools/modulesmodules to load when booting the initramfs. /usr/share/initramfs-tools/modules like /etc/initramfs-tools/modules. /usr/share/initramfs-tools/modules.d/ modularized 'modules' i find duplicate places to put something quite a bit irritating. is there some functional advantage i just don't get? otherwise i'd suggest adding an /etc/initramfs-tools/modules.d/, removing all the duplicate places keeping the /etc/initramfs-tools/* versions, and removing the hooksconf.d/. also i don't think it would be wrong to move the /usr/share/initramfs-tools/conf.d/ to something like /etc/initramfs-tools/initramfs-conf.d/, and also move the hook-functions and init to /etc/initramfs-tools/ - so the whole /usr/share/initramfs-tools/ could be spared. in case of general approval, i'd provide a patch for this and could also take care to provide patches for the packages currently using /usr/initramfs-tools/ as far as i know of them (currently that would be: cryptsetup, dropbear, uswsusp, udev). hm. actually that could be optimized even more. for example when building a cryptroot+dropbear initramfs, the host keys and authorization info for the initramfs is created and saved into /etc/initramfs-tools/ (in etc/ and root/). a kind of 'initramfs template root' could be created (e.g. /etc/initramfs-tools/template/ or /etc/initramfs-tools/initramfs/), and the mentioned etc/ and root/ could be moved there. scripts/, conf/conf.d/, conf/modules and conf/modules.d/ (i.e. all the stuff that is meant to end up in the initramfs) could be moved there, too, so when creating an initramfs, this template dir could simply be used as a starting point. this way mkinitramfs could be reduced in complexity quite a bit i guess, while this should also add some degree of transparency and also flexibility for future features (esp. features by other packages, i guess). of course i'd also be happy to provide a patch for this, in case it is regarded as a good thing [tm]. and to answer my initial question, i guess using conf.d/ for modularized configs done by other packages is a good idea. :) regarding dropbear: patch for the dropbear package attached. gerrit, in case you approve of this patch but would like me to open a bug for dropbear with this patch, please just drop me a short note. 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.0 +0100 +++ ./dropbear-0.52/debian/initramfs/dropbear-conf 2010-03-25 11:48:38.0 +0100 @@ -6,3 +6,12 @@ # #DROPBEAR=y + +# +# UMASK: [ 4-DIGIT OCTAL UMASK ] +# +# umask to use when creating an initramfs +# + +UMASK=0077 + diff -pruN ../a/dropbear-0.52/debian/rules ./dropbear-0.52/debian/rules --- ../a/dropbear-0.52/debian/rules 2010-03-25 11:42:21.0 +0100 +++ ./dropbear-0.52/debian/rules 2010-03-25 12:13:46.0 +0100 @@ -92,9 +92,9 @@ install: deb-checkdir deb-checkuid build '$(DIR)'/usr/share/initramfs-tools/scripts/init-bottom install -m0755 debian/initramfs/bottom-dropbear \ '$(DIR)'/usr/share/initramfs-tools/scripts/init-bottom/dropbear - install -d -m0755 '$(DIR)'/usr/share/initramfs-tools/conf-hooks.d + install -d -m0755 '$(DIR)'/etc/initramfs-tools/conf.d install -m0644 debian/initramfs/dropbear-conf \ - '$(DIR)'/usr/share/initramfs-tools/conf-hooks.d/dropbear + '$(DIR)'/etc/initramfs-tools/conf.d/dropbear # man pages install -d -m0755 '$(DIR)'/usr/share/man/man8 for i in dropbear.8 dropbearkey.8; do \
Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users
On Thu, Mar 25, 2010 at 02:46:35PM +0100, deb...@x.ray.net wrote: maximilian attems wrote: egrep UMASK /etc/initramfs-tools/initramfs.conf UMASK=0077 this was not yet documented in initramfs.conf.5, will be in next upload. ah ic. :) in this case i guess it were a good idea to automatically set UMASK=0077 in the initramfs config when installing dropbear. yep regarding initramfs-tools: 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. when trying to locate the best[tm] place to put this, i first got a bit confused, and concluded with these findings regarding intramfs-tools in the end: your overview totaly confused me and partialy wrong let's start with important things, please checkout man initramfs-tools. 1) scripts to add stuff to initramfs /usr/share/initramfs-tools/hooks /etc/initramfs-tools/hooks 2) boot scripts /usr/share/initramfs-tools/scripts /etc/initramfs-tools/scripts 3) conf for mkintramfs for packages (does not land in initramfs) /usr/share/initramfs-tools/conf-hooks.d/ 4) conf for boot scripts /usr/share/initramfs-tools/conf.d/ /etc/initramfs-tools/conf.d/ modules loading is a seperate story and is added in /usr/share/initramfs-tools/modules and corresponding file in /etc old unused dir is /usr/share/initramfs-tools/hooksconf.d 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. concerning templating this is what each perl module likes to reinvent badly, don't think we need that complexity. 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. regarding dropbear: patch for the dropbear package attached. gerrit, in case you approve of this patch but would like me to open a bug for dropbear with this patch, please just drop me a short note. seems good in general, just the packaging change can be dropped. 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.0 +0100 +++ ./dropbear-0.52/debian/initramfs/dropbear-conf2010-03-25 11:48:38.0 +0100 @@ -6,3 +6,12 @@ # #DROPBEAR=y + +# +# UMASK: [ 4-DIGIT OCTAL UMASK ] +# +# umask to use when creating an initramfs +# + +UMASK=0077 + diff -pruN ../a/dropbear-0.52/debian/rules ./dropbear-0.52/debian/rules --- ../a/dropbear-0.52/debian/rules 2010-03-25 11:42:21.0 +0100 +++ ./dropbear-0.52/debian/rules 2010-03-25 12:13:46.0 +0100 @@ -92,9 +92,9 @@ install: deb-checkdir deb-checkuid build '$(DIR)'/usr/share/initramfs-tools/scripts/init-bottom install -m0755 debian/initramfs/bottom-dropbear \ '$(DIR)'/usr/share/initramfs-tools/scripts/init-bottom/dropbear - install -d -m0755 '$(DIR)'/usr/share/initramfs-tools/conf-hooks.d + install -d -m0755 '$(DIR)'/etc/initramfs-tools/conf.d install -m0644 debian/initramfs/dropbear-conf \ - '$(DIR)'/usr/share/initramfs-tools/conf-hooks.d/dropbear + '$(DIR)'/etc/initramfs-tools/conf.d/dropbear # man pages install -d -m0755 '$(DIR)'/usr/share/man/man8 for i in dropbear.8 dropbearkey.8; do \ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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.0 +0100 +++ ./dropbear-0.52/debian/initramfs/dropbear-conf 2010-03-25 11:48:38.0 +0100 @@ -6,3 +6,12 @@ # #DROPBEAR=y + +# +# UMASK: [ 4-DIGIT OCTAL UMASK ] +# +# umask to use when creating an initramfs +# + +UMASK=0077 +
Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users
hello! On Thu, Mar 25, 2010 at 07:18:46PM +0100, deb...@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.0 +0100 +++ ./dropbear-0.52/debian/initramfs/dropbear-conf2010-03-25 11:48:38.0 +0100 @@ -6,3 +6,12 @@ # #DROPBEAR=y + +# +# UMASK: [ 4-DIGIT OCTAL UMASK ] +# +# umask to use when creating an initramfs +# + +UMASK=0077 + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users
retitle 536195 document UMASK initramfs.conf usage stop ls -l /boot/initrd.img-2.6.33-2-amd64 -rw--- 1 root root 9589266 Mar 25 03:03 /boot/initrd.img-2.6.33-2-amd64 egrep UMASK /etc/initramfs-tools/initramfs.conf UMASK=0077 this was not yet documented in initramfs.conf.5, will be in next upload. thanks for report. -- maks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users
On Tue, Sep 01, 2009 at 12:44:50PM +0200, deb...@x.ray.net wrote: However, using stock initramfs-tools, the keys then get placed into a world-readable initramfs, allowing any account on the server to extract the host keys directly: you're right. but this is actually not an issue of the dropbear package. building the initramfs is done with update-initramfs which uses mkinitramfs, both are part of initramfs-tools. so i guess this bugreport should be moved to the package initramfs-tools. Hi, if so, please re-assign to the appropriate package, and take care of it ;). Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users
hi!
However, using stock initramfs-tools, the keys then get placed into a
world-readable initramfs, allowing any account on the server to
extract the host keys directly:
you're right.
but this is actually not an issue of the dropbear package. building the
initramfs is done with update-initramfs which uses mkinitramfs, both are part
of initramfs-tools.
so i guess this bugreport should be moved to the package initramfs-tools.
i know this can be done, but i haven't done that yet (and i'm not sure whether
this can only be done by package maintainers) and i guess having somebody who
knows what he's doing actually doing this is to be preferred... :)
if i got that right, possible straightforward solutions would be preferably to change
'umask 0022' in line 3 of /usr/sbin/mkinitramfs to 'umask 0077', or to add 'chmod 600
${outfile}' before the last if-block in /usr/sbin/mkinitramfs if the umask
shouldn't be changed for other reasons.
regards,
Chris
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users
Package: dropbear
Version: 0.52-2
Severity: normal
the dropbear package takes pains to set up the initramfs with its own
host keys for remote boot. This is good!
It also makes those host keys unreadable to non-root users. This is
also good!
0 d...@pip:/tmp$ ls -l /etc/initramfs-tools/etc/dropbear/dropbear_*
-rw--- 1 root root 459 2009-07-08 00:08
/etc/initramfs-tools/etc/dropbear/dropbear_dss_host_key
-rw--- 1 root root 426 2009-07-08 00:08
/etc/initramfs-tools/etc/dropbear/dropbear_rsa_host_key
0 d...@pip:/tmp$
However, using stock initramfs-tools, the keys then get placed into a
world-readable initramfs, allowing any account on the server to
extract the host keys directly:
0 d...@pip:/tmp$ mkdir -p etc/dropbear
0 d...@pip:/tmp$ zcat /boot/initrd.img-$(uname -r) | cpio --extract
etc/dropbear/dropbear_{dss,rsa}_host_key
40323 blocks
0 d...@pip:/tmp$ ls -l etc/dropbear/
total 8
-rw--- 1 dkg dkg 459 2009-07-08 00:45 dropbear_dss_host_key
-rw--- 1 dkg dkg 426 2009-07-08 00:45 dropbear_rsa_host_key
0 d...@pip:/tmp$
This exposes the remote boot setup to a potential MITM attack by any
system user who cared to copy the host keys out of the initramfs
before the reboot and is able to intercept (or misroute) network
traffic.
One really bad otucome of this is that it could allow for sniffing of
the cryptoroot passphrases.
--dkg
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-vserver-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dropbear depends on:
ii libc6 2.9-12GNU C Library: Shared libraries
ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime
dropbear recommends no packages.
Versions of packages dropbear suggests:
ii openssh-client 1:5.1p1-5.opensc1 secure shell client, an rlogin/rsh
ii runit 2.0.0-1 a UNIX init scheme with service su
ii udev 0.141-1 /dev/ and hotplug management daemo
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
