How to prevent new installations when I have already installed my client through LAN boot?

[Michał Dwużnik]

Hi Thomas,

On Thu, Feb 9, 2012 at 10:41, Thomas Neumann <blacky+fai at fluffbunny.de> wrote:
> Please note: I haven't used fai-chboot to automatically disable
> fai-installation yet because the manpage scares me too much. What is
> described in this mail is an attack scenario that seems to be possible
> judging from the manpage.
>

I don't see big flashing 'thou are forbidden to harden your install as
you see fit' in the manpage either.


I will address only 'first glance' issues below:

>> have a look there:
>> https://lists.uni-koeln.de/pipermail/linux-fai/2009-October/007357.html
>
> There should be a big fat flashing warning sign attached to fai-chboot + ssh.
>

'no guarantee' as always. Feel free to contribute and provide better schema.
The software as is may not be 'good enough' for you. But it surely is
for the others,
as you said in the conclusion.

I fail to see why
"
THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
"
should not apply in this case.


> Does nobody see the fault in having
>
>  - a NFS-share mountable by any client [on a specific network]

_any_ client?  Only if you totally don't care about preparing the
exports file...
Not to mention quite old, crude, but well adopted ways of limiting the access
to NFS server via ethers/arpwatch combo.


>  - a SSH-Key without a passphrase stored in that NFS-share
>  - a login account allowing (at least) the manipulation of other hosts
> boot-settings
>

Limiting access through ssh on the business address of your fai server
to sume short list of machines is
pretty much straightforward.


> It gets worse.
>
> NFS traffic is not even encrypted. This means the private key is
> transmitted in plaintext over the wire. From a security point of view
> there's not much difference if one simply uses telnet instead of ssh.
>

True 'as is' in fai - not true in general. NFS traffic can be encrypted.
Feel free to add krb5p to fai features.

>
> This is probably not relevant if using fai to install a compute-cluster in
> a trusted network environment. If the environment is not trusted (training
> classroom? datacenter?) then please implement appropriate measures.
>

'Please implement'?
Sorry, I'm not the developer of FAI. Nor is Ivan  AFAIK.
And I think you're not the funding agency behind Thomas Lange either.

Feel very welcome to use whatever method you see fit for your environment,
there are numerous known cases of successful donations to the devs
upon a feature request, too
(with no implied guarantee this would work here and now).


Regards
Michal Dwuznik