Hi Thomas, On Thu, Feb 9, 2012 at 10:41, Thomas Neumann <[email protected]> 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
