Thanks for involving us again. We will schedule a review and report back.

Using a separate D-Bus is really quite special ...

Are you currently block on anything from our side (i.e. whitelisting
restrictions)?

I personally won't be available for this review for the next two weeks. If it
is urgent then we can raise the priority for the review and maybe a colleague
takes over.

After looking a bit closer into the references URLs I wonder if you can give
us a current design summary?

So Iguana runs a container during initrd time. And this is now somehow
containing parts of all of d-installer?

How exactly is this D-Bus bus in the container related to the rest of the
system?

Is the assumption from the previous review still true that this will only be
run in live ISO environments and not ever in a production environment?

I will try to summarize. We have two different use-cases: Iguana and the Live media. I will start talking about Iguana because it is the reason to introduced our own dbus-daemon.

# The Iguana use-case

Iguana is a module that allows running containers from initrd. Iguana starts two containers, dinstaller-backend and dinstaller-web. The network is handled by NetworkManager, running on the host (that's an important detail).

Apart from talking to each other, the D-installer containers need to interact with NetworkManager. So we decided to:

* Have a private dbus-daemon for D-Installer internal communication.
* Connect to the host D-Bus daemon to interact with the system (Network or any other service we might need).

We could not use the host daemon because, from the containers, we cannot change its configuration.

# The Live use-case

As a side effect of the previous use case, on a Live system you have three daemon servers: system, session and d-installer (once the service is started). If d-installer is not started, the daemon should not be there.

And yes, d-installer is meant to be used as an installer, so it is not expected to run on a production system. However, it is available as a package -to be included in the ISO-, so perhaps we might want to add some kind of restriction.

About the priority, D-Installer is one of the ways to install ALP, but I do not think we are in a hurry. It is, as commented, not expected to be used on a production system.

Thanks in advance!

I will work on this now.

So from your description in comment 4 it sounds like the addition a D-Bus
instance is kind of private to the two containers for backend and the web
components. Is that true? Can the UNIX domain socket be accessed from the host
system otherwise?

Of course the interface of d-installer can be accessed indirectly via the web
component, I suppose. Will this listen on localhost or also on remotely
accessible network interfaces by default?

The separate D-Bus instance only shared by the two containers sounds like it
improves the isolation on D-Bus level so I have no problem with that.
Although the use of containers on initrd level sounds pretty complex, design
wise.

What I meant by asking if you are blocked by us is whether you are hitting any
whitelisting restrictions that we need to fix? But I don't think so.

(In reply to Matthias Gerstner from comment #7)

Hi Matthias,

First of all, D-Installer has been renamed to Agama[1]. But they are the same thing code-wise.

> So from your description in comment 4 it sounds like the addition a D-Bus
> instance is kind of private to the two containers for backend and the web
> components. Is that true? Can the UNIX domain socket be accessed from the
> host
> system otherwise?

Yes, it is a private D-Bus instance and we have limited access to just the root user: https://github.com/openSUSE/agama/blob/master/service/share/dbus.conf.

> Of course the interface of d-installer can be accessed indirectly via the web
> component, I suppose. Will this listen on localhost or also on remotely
> accessible network interfaces by default?

It uses cockpit infrastructure for that, so it is available remotely too (not only in localhost). But if you access it remotely, it asks for a user/password. The problem is that, at this point, the user/password is a known one. Thinking about that, I guess we should ask the user to explicitly enable the remote access (and offer a way to set the root password at boot time).

> The separate D-Bus instance only shared by the two containers sounds like it
> improves the isolation on D-Bus level so I have no problem with that.
> Although the use of containers on initrd level sounds pretty complex, design
> wise.

Agama does not rely on containers at all. You can run Agama in two different ways:

* Using our Live media[2]. In that case, it does not rely on containers, although it still uses a private D-Bus instance.
* On top of Iguana[3], running a container for the service and another for the web interface. Actually, we introduced the private D-Bus instance for this scenario.

> 
> What I meant by asking if you are blocked by us is whether you are hitting
> any
> whitelisting restrictions that we need to fix? But I don't think so.

No, we are not blocked, everything is working fine. Thanks for having a look. I will keep you informed if we introduced any relevant change.

Regards,
Imo

[1] https://github.com/openSUSE/agama/pull/509
[2] https://build.opensuse.org/package/show/YaST:Head:Agama/agama-live
[3] https://github.com/openSUSE/iguana

BTW, the "new" package is https://build.opensuse.org/package/show/YaST:Head:Agama/rubygem-agama.

(In reply to igonzalezsosa@suse.com from comment #8)

> It uses cockpit infrastructure for that, so it is available remotely too (not only in localhost). But if you access it remotely, it asks for a user/password. The problem is that, at this point, the user/password is a known one. Thinking about that, I guess we should ask the user to explicitly enable the remote access (and offer a way to set the root password at boot time).

Allowing arbitrary access to the installation environment from the network is
bad, so yes, please avoid it.

> No, we are not blocked, everything is working fine. Thanks for having a look. I will keep you informed if we introduced any relevant change.

Is there some installation medium available where we can take a look at the
integration of agama?

Otherwise on the theoretical level there's not much else to discuss I believe.

Hi Matthias,

The current ISO is available here for several architectures:

https://build.opensuse.org/package/show/YaST:Head:Agama/agama-live

I hope it helps.

This is an autogenerated message for OBS integration:
This bug (1208394) was mentioned in
https://build.opensuse.org/request/show/1090476 Factory / rpmlint

JFYI, we are moving Agama packages to systemsmanagement:Agama:Devel (the devel project) and systemsmanagement:Agama:Staging (building packages from Git).

[1] https://build.opensuse.org/project/show/systemsmanagement:Agama:Devel
[2] https://build.opensuse.org/project/show/systemsmanagement:Agama:Staging

I want to dig around a bit in the live installation environment to come to a
conclusion with this review.

The agama-live package currently fails to build though so I don't have an ISO
to use.

On the rpmlint side I removed the whitelistings for the D-Bus services that I
previously instated, since they are no longer necessary with the new approach
of using a separate D-Bus.

Okay I managed to find and download the ISO (multibuild OBS packages are
weird).

What is the root password for connecting via SSH while the installer runs?

Is there already a web version of the installer active on the ISO?

Hi Matthias,

Thanks for having a look.

The password is "linux" and, yes, the web UI is available on https://<IP>:9090/. I guess we should disable the server and allow a boot option to enable the server and set the password (e.g., agama.server=1 agama.rootpw=mypassword).

What do you think?

Regards,
Imo

Thanks for the additional info.

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.

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.

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.

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.

(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

Thanks for the feedback. I guess we can close this AUDIT bug here for now. The
D-Bus part is finished from my POV. Regarding the remote access features of
the new installer you can create a separate AUDIT bug for us once you have
something new.

Thanks Matthias! I will create the new AUDIT once we have something to review.

Regards,
Imo