On Mon, Nov 16, 2009 at 10:44:38PM +0600, Ivan Shmakov wrote:
> Do I understand correctly that the netbooting Debian Live is
> currently inherently insecure against both eavesdroppers and
> intruders?
PXE is indeed inherently insecure.
>
> I see that even if the gPXE option to securily check the kernel
> and initramfs images after downloading is used, NFS has still to
> be secured separately.
This relies on running gPXE code. And this means you have to replace the
boot media if you change the kernel and/or the initramfs. The initramfs
in Debian Live can certainly change on configuration changes (and is
recreated each time you build the system anyway).
>
> Anyway, the process of establishing the secure connection to the
> netboot server depends on a kind of secure ``token'' (say, a
> private key and an X.509 certificate.) Do I understand it
> correctly that, in principle, the availability of such a token
> early during the boot process may allow for the whole netboot
> process to be secure?
What is your threat model?
>
> The secure token may, e. g., be embedded into the initramfs
> image, which, together with the kernel, may be stored on a
> removable media, such as a USB Flash or a CD-R (DVD+R) disk.
A uniqueue key for each media? Why? The initramfs may contain
customizations and I would like to occasionally rebuild it.
Redistributing it for every media would not be fun.
So can easily add an extra key onto the media itself, though.
And then again, why would the server trust on the client's report of
this unique checksum in the first place? What is the point of it being
unique? I get the feeling you have your own system for providing unique
IDs (and you don't like using e.g. MAC addresses for various reasons).
Could you provide more information about it?
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.co...@xorcom.com
+972-50-7952406 mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
