Bug 1219688

Can you please point us to the package / source used for this?

Is there an installation media available where this is already integrated?

Note: we reviewed the agama installer last in bug 1208394.

Hi Matthias,

We have no code yet. Just wanted to know if there was anything flawed in the approach. We expect to have something working during the following weeks. If you prefer, I would close this issue and reopen it when there is some real code to check.

Is it ok?

Thanks!

Ah okay, I missed that bit, that this is only in the design phase yet.

Since this will be using TLS, how will the certificate trust be handled? With
self-signed certificates some form of fingerprint verification would need to
happen.

Otherwise the main worry for this component will continue to be that nobody
can access the system over the network at any stage without authentication of
some form.

I will ask a colleague of mine, Paolo, to chime in. He's a specialist for web
APIs.

Hi Matthias,

Yes, you are right. We must display the fingerprint somehow and/or allow the users to inject their certificates. It is pretty similar to the current version based on Cockpit.

I'm looking forward to Paolo's input!

Thanks!

Hi everybody. Just some random inputs for JWT.
Please make sure to sign or encrypt the token with JWT specific facilities, transferring it only on HTTPS and if you will store it in a cookie to set it as HttpOnly and Secure.

There is also a Owasp provided cheatsheet for JWT tokens you can find here: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html

Another point of attention is for digital cerficate. Please make sure to let the client validate the certificate when doing HTTPS calls. However I didn't understand the scenario... both client and server will run on the same host, correct?

(In reply to Paolo Perego from comment #5)

Hi Paolo,

> Hi everybody. Just some random inputs for JWT.
> Please make sure to sign or encrypt the token with JWT specific facilities,
> transferring it only on HTTPS and if you will store it in a cookie to set it
> as HttpOnly and Secure.

OK, noted.

> There is also a Owasp provided cheatsheet for JWT tokens you can find here:
> https://cheatsheetseries.owasp.org/cheatsheets/
> JSON_Web_Token_for_Java_Cheat_Sheet.html

Thanks! We will have a look.

> Another point of attention is for digital cerficate. Please make sure to let
> the client validate the certificate when doing HTTPS calls. However I didn't
> understand the scenario... both client and server will run on the same host,
> correct?

Which is the right way to validate the certificate? Allowing the user to check the fingerprint?

The client and the server might run on different machines. You can install the system locally (using a browser that runs on the same machine and connects to "localhost") or remotely using your browser.

Following Cockpit's approach, when connecting to localhost, we do not see the need to use HTTPS. But when installing remotely, it is mandatory. Does it make sense?

Regards,
Imo

(In reply to Imobach Gonzalez Sosa from comment #6)
> (In reply to Paolo Perego from comment #5)

[snip]

> > Another point of attention is for digital cerficate. Please make sure to let
> > the client validate the certificate when doing HTTPS calls. However I didn't
> > understand the scenario... both client and server will run on the same host,
> > correct?
> 
> Which is the right way to validate the certificate? Allowing the user to
> check the fingerprint?
Ok well... interacting with the browser, using a valid certificate, not self signed. Interacting with a command line client, having the client validating all the root of trust of the certificate.

eg:

> import requests
> requests.post(url='https://foo.example', data={'bar':'baz'})

> Following Cockpit's approach, when connecting to localhost, we do not see
> the need to use HTTPS. But when installing remotely, it is mandatory. Does
> it make sense?
It would require a lot of extra effort dividing the two cases... however it makes sense to have http on a localhost only communication.

(In reply to Paolo Perego from comment #7)

[..]

> Ok well... interacting with the browser, using a valid certificate, not self
> signed. Interacting with a command line client, having the client validating
> all the root of trust of the certificate.

Well, bear in mind that you do not know the name or IP address the system will use when running (after all, it is a live DVD). What we do these days in Agama is to use a self-signed certificate (generated by Cockpit) and allow the user to use his/her own certificate (specifying a URL to get the certificate as a kernel cmdline option).

Not to mention than using a proper certificate would need you to distribute such a certificate (including the private key) in the media.

Or perhaps the problem is that I am lost :-)

> eg:
> 
> > import requests
> > requests.post(url='https://foo.example', data={'bar':'baz'})
> 

[..]

(In reply to Imobach Gonzalez Sosa from comment #8)
> (In reply to Paolo Perego from comment #7)

[snip]

> Well, bear in mind that you do not know the name or IP address the system
> will use when running (after all, it is a live DVD). What we do these days
> in Agama is to use a self-signed certificate (generated by Cockpit) and
> allow the user to use his/her own certificate (specifying a URL to get the
> certificate as a kernel cmdline option).

Correct.

I will take in charge this audit. Can you please share with me a roadmap to understand when the code will be available to audit?
So I can schedule the activities.

Thank you
Paolo

Hi Paolo,

Thanks a lot for having a look. Our (now updated) roadmap is in Confluence:

https://confluence.suse.com/display/YAST/Project+Roadmap

The changes should be included in milestone 1 (mid-April), but we can report on the progress as soon as we start working (this week).

Regards,
Imo

Docs about security concepts in agama: https://github.com/openSUSE/agama/blob/architecture_2024/doc/agama-security.md

Hi everyone,

We have moved the security concepts documentation to a new location[1]. Additionally, we have reorganized all the documentation a bit, and we have updated the description of the architecture[2].

We are working on building a new ISO image containing the latest code. I will ping you when it is ready.

[1] https://github.com/openSUSE/agama/blob/master/doc/security.md
[2] https://github.com/openSUSE/agama/blob/master/doc/architecture.md

(In reply to Imobach Gonzalez Sosa from comment #12)
> Hi everyone,
> 
> We have moved the security concepts documentation to a new location[1].
> Additionally, we have reorganized all the documentation a bit, and we have
> updated the description of the architecture[2].
> 
> We are working on building a new ISO image containing the latest code. I
> will ping you when it is ready.
> 
> [1] https://github.com/openSUSE/agama/blob/master/doc/security.md
> [2] https://github.com/openSUSE/agama/blob/master/doc/architecture.md

Thanks

Hi all,

The new code has been included in the official image for quite some time already, so perhaps you might want to have a look. The documents in comment 12 still apply.

You can grab a new image at https://download.opensuse.org/repositories/systemsmanagement:/Agama:/Devel/images/

Thanks!