Comment # 18 on bug 1208394 from Imobach Gonzalez Sosa

(In reply to Matthias Gerstner from comment #17)
> Thanks for the additional info.

You are welcome!

> During testing the live ISO it happened once right after booting that the
> installer couldn't come up properly, displaying "Cannot connect to D-Bus".
> Pressing "Reload" fixed this though. There still seems to be some instability
> there.

We have improved the startup process (relying on D-Bus activation), so I expect
this problem to be fixed. Anyway, we will do some further testing for the next
release.

> 
> Security wise I belive the D-bus specific parts are not that critical, since
> they only run in the live environment. All processes are root there currently
> anyway. I had a look at the agama D-Bus configuration and its socket
> directory
> in /run/amaga etc. It looks okay.

OK, great.

> Looking at the bigger picture of this installer the challenges lie rather in
> the way people get remote access to this live environment / the installer.
> Currently we have two methods:
> 
> - root login via password on the SSH port 22 which is enabled by default.
> 
> - root login via the web browser on SSL port 9090 which is also enabled by
>   default. This web server uses a self-signed SSL certificate that is not
>   trusted.
> 
> An installer in this form should not be used in production since it can be
> hijacked anytime once connected to a real network. We also should not rely on
> a trusted network environment here.
> 
> The root user should use a random password on SSH level. This random password
> could be displayed in the graphical installer.
> 
> For the web server, if it cannot use a properly trusted SSL certificate, the
> SSL fingerprint could be displayed in the graphical installer (on the
> local console) for verification. Also the login on web level needs to be made
> safe some way, again the password could be displayed on the local console.

It makes sense. I had though about disabling remote access by default and
allowing the user to enable it through some boot argument, similar to what we
do in SLES (e.g., ssh=1 sshpassword=foobar).

However, displaying the password and the fingerprint looks like a better idea.

> The SSH login (which probably isn't needed often, it's more kind of a
> developer/expert access) could also be bootstrapped via the web server. The
> web server could offer the (trusted) download of a randomly generated SSH
> private key.

Sure, the SSH login is an expert/developer feature. I like the idea of
generating a private key and enabling the service.

Thanks a lot for your feedback, Matthias. I will coordinate with the team to
work on this. I will keep you informed.

Regards,
Imo