https://bugzilla.suse.com/show_bug.cgi?id=1208394 https://bugzilla.suse.com/show_bug.cgi?id=1208394#c18 --- Comment #18 from Imobach Gonzalez Sosa <igonzalezsosa@suse.com> --- (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 -- You are receiving this mail because: You are on the CC list for the bug.