FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 03-25-2010, 01:10 AM
maximilian attems
 
Default 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-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100325021003.GK21407@stro.at">http://lists.debian.org/20100325021003.GK21407@stro.at
 
Old 03-25-2010, 12:46 PM
 
Default 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/modules modules 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
 
Old 03-25-2010, 03:16 PM
maximilian attems
 
Default Bug#536195: dropbear remote boot feature exposes initramfs host keys to regular users

On Thu, Mar 25, 2010 at 02:46:35PM +0100, debian@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.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
> +
> 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.000000000 +0100
> +++ ./dropbear-0.52/debian/rules 2010-03-25 12:13:46.000000000 +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-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100325161627.GT22870@baikonur.stro.at">http://lists.debian.org/20100325161627.GT22870@baikonur.stro.at
 
Old 03-25-2010, 05:18 PM
 
Default 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
 
Old 03-25-2010, 07:52 PM
maximilian attems
 
Default 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
> +




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100325205225.GU22870@baikonur.stro.at">http://lists.debian.org/20100325205225.GU22870@baikonur.stro.at
 
Old 03-26-2010, 03:34 PM
 
Default 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
 

Thread Tools




All times are GMT. The time now is 10:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org