Diese Nachricht wurde eingewickelt um DMARC-kompatibel zu sein. Die
eigentliche Nachricht steht dadurch in einem Anhang.
This message was wrapped to be DMARC compliant. The actual message
text is therefore in an attachment.--- Begin Message ---
Hello,
In the case of public network and no access to the machine at time of
installation, I think this is unsolvable in principle.
Imagine the following scenario, say on a school on university network: an
attacker (perhaps just a curious student) sets up a virtual machine with the
MAC address and emulated hardware identical to a physical machine that would be
installed by FAI. Then he disconnects the actual machine (say, in a computer
classroom) and initiates a FAI install on his VM. Any exchange of secrets that
would take place with the real machine now takes place with the student's VM.
Afterwards, he takes the VM image home and can extract any secrets that were
transferred to it during install.
Some things that I can imagine that could mitigate such risks would be:
- Inputting some secret on the physical machine during install (from the
keyboard, USB stick, etc). This would defeat the idea of "fully automatic"
install.
- Pre-loading a secret onto hardware (is this what you mean by using TPM?).
- Time-limiting the availability of secrets and/or some component of FAI. Most
of us probably do not install clients every day, all day.
- Monitoring of installation processes and flagging abnormal activities. This
would not prevent successful attacks, but possible breaches could be patched
up, eg keys replaced afterwards.
BR,
Toomas
-Original Message-
From: linux-fai On Behalf Of Diego Zuccato
Sent: kolmapäev, 14. detsember 2022 07:40
To: linux-fai@uni-koeln.de
Subject: Re: Secure deploy of keys
Tks.
Too bad I fear it's not applicable to my scenario.
First because the network is public. Second because ssh is just one of
the secrets I have to distribute (others are usually SaltStack key and
Gluster certificate).
I'm thinking that probably this is one of the few cases where a TPM is
actually useful...
GPG encrypted tarballs can be a good solution if there's a trusted
person that can insert the password (or a tpm that can decrypt it) to
complete the install...
Diego
Il 13/12/2022 20:44, Andrew Ruthven ha scritto:
> Hey,
>
> On Tue, 2022-12-13 at 14:47 +0100, Diego Zuccato wrote:
>> What's the recommended way to deploy (or re-deploy) security-sensitive
>> objects (just to say one: private ssh key to avoid client warnings when
>> redeploying a server)?
>
> For things like ssh host keys I have a command that we run which copies
> them into the NFSROOT, and then a cron job that runs every minute that
> removes "expired" files from the NFSROOT. Given our NFSROOT is on a
> restricted network I feel that is sufficient.
>
> I know someone who had GPG encrypted tarballs, but that required
> entering a passphrase during the build process.
>
> Another option for ssh which I am considering is using PKI for it. Then
> servers and clients just need to trust a CA.
>
> Cheers,
> Andrew
>
> --
>
> Andrew Ruthven, Wellington, New Zealand
> and...@etc.gen.nz |
> Catalyst Cloud: | This space intentionally left blank
> https://catalystcloud.nz |
>
--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786
--- End Message ---
