On Tue, Mar 27, 2018 at 9:25 AM, Andrei Borzenkov wrote:

27.03.2018 09:39, Roger Oberholtzer пишет:

...

Is there a description of the idea/method behind the use of certificates to ensure that one (zypper?) is getting software from the real repository?

Where you get software from is more or less irrelevant for RPM based distribution. Each package is signed and signature is checked during installation. Just make sure to control which keys are imported by RPM as trusted and do not install packages with unknown signature.

This I know. But I would like to have some description of how this is set up for openSUSE repositories so that I can suggest to our company that perhaps openSUSE repos can be added to the white list. zypper must add an additional check that the source of the RPM and not just the RPM itself is as expected. Isn't that why it asks for acknowledgment that the repo is the expected one when the repo is first added to it's list of repos? Or maybe it is that the repo's certificate is in the RPM as well. That's the point: I would like to be able to explain how this is done to those who make the decisions. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 27 Mar 2018 09:46:24 +0200 Per Jessen wrote:

Roger Oberholtzer wrote:

...

On Tue, Mar 27, 2018 at 9:25 AM, Andrei Borzenkov wrote:

...

27.03.2018 09:39, Roger Oberholtzer пишет:

...

Is there a description of the idea/method behind the use of certificates to ensure that one (zypper?) is getting software from the real repository?

Where you get software from is more or less irrelevant for RPM based distribution. Each package is signed and signature is checked during installation. Just make sure to control which keys are imported by RPM as trusted and do not install packages with unknown signature.

This I know. But I would like to have some description of how this is set up for openSUSE repositories so that I can suggest to our company that perhaps openSUSE repos can be added to the white list.

Plus all the mirrors. Maybe you would need to dedicate one?

Hi Roger, I just discovered https://doc.opensuse.org/documentation/leap/security/html/book.security/inde... Who knew such a thing existed? Sadly it doesn't seem to cover software installation. Maybe you should write to doc-team@suse.com and ask them whether what you need is documented elsewhere or should be added to that guide? Or ask on the opensuse-security@opensuse.org list? The most I found in the document is on https://doc.opensuse.org/documentation/leap/security/html/book.security/cha.... where it says: " Take proper care when installing any third-party software. There have been cases where a hacker had built a Trojan horse into the TAR archive of a security software package, which was fortunately discovered very quickly. If you install a binary package, have no doubts about the site from which you downloaded it. "SUSE's RPM packages are gpg-signed. The key used by SUSE for signing is: "ID:9C800ACA 2000-10-19 SUSE Package Signing Key Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA "The command rpm --checksig package.rpm shows whether the checksum and the signature of an uninstalled package are correct. Find the key on the first CD of the distribution and on most key servers worldwide." But I expect you would like further detail. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hi, On Tue, Mar 27, 2018 at 09:49:50AM +0100, Dave Howorth wrote:

On Tue, 27 Mar 2018 09:33:50 +0100 Dave Howorth wrote:

...

On Tue, 27 Mar 2018 09:46:24 +0200 Per Jessen wrote:

...

Roger Oberholtzer wrote:

...

On Tue, Mar 27, 2018 at 9:25 AM, Andrei Borzenkov wrote:

...

27.03.2018 09:39, Roger Oberholtzer пишет:

...

Is there a description of the idea/method behind the use of certificates to ensure that one (zypper?) is getting software from the real repository?

Where you get software from is more or less irrelevant for RPM based distribution. Each package is signed and signature is checked during installation. Just make sure to control which keys are imported by RPM as trusted and do not install packages with unknown signature.

This I know. But I would like to have some description of how this is set up for openSUSE repositories so that I can suggest to our company that perhaps openSUSE repos can be added to the white list.

Plus all the mirrors. Maybe you would need to dedicate one?

Hi Roger,

I just discovered https://doc.opensuse.org/documentation/leap/security/html/book.security/inde...

Who knew such a thing existed? Sadly it doesn't seem to cover software installation. Maybe you should write to doc-team@suse.com and ask them whether what you need is documented elsewhere or should be added to that guide? Or ask on the opensuse-security@opensuse.org list?

The most I found in the document is on https://doc.opensuse.org/documentation/leap/security/html/book.security/cha.... where it says:

" Take proper care when installing any third-party software. There have been cases where a hacker had built a Trojan horse into the TAR archive of a security software package, which was fortunately discovered very quickly. If you install a binary package, have no doubts about the site from which you downloaded it.

"SUSE's RPM packages are gpg-signed. The key used by SUSE for signing is:

"ID:9C800ACA 2000-10-19 SUSE Package Signing Key Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA

"The command rpm --checksig package.rpm shows whether the checksum and the signature of an uninstalled package are correct. Find the key on the first CD of the distribution and on most key servers worldwide."

But I expect you would like further detail.

Here's a bit more, about SLES rather than Leap though:

https://www.suse.com/support/security/download-verification/

Better like this... hmm. https://en.opensuse.org/SDB:Secure_installation_sources Explains the concept. Basically the YUM or YAST repositories we deliver have a root "content" file or "repomd.xml" that is signed by the openSUSE build key.

From this root content file all other meta data and RPM files are referenced explicitly with SHA256 checksums.

So once you have the trust base as the openSUSE build key libzypp verifies the whole content chain based on that. The key is shipped in the media. This allows mirror redistribution without decrease in security. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

27.03.2018 12:46, Carlos E. R. пишет:

On 2018-03-27 09:25, Andrei Borzenkov wrote:

...

27.03.2018 09:39, Roger Oberholtzer пишет:

...

Is there a description of the idea/method behind the use of certificates to ensure that one (zypper?) is getting software from the real repository?

Where you get software from is more or less irrelevant for RPM based distribution. Each package is signed and signature is checked during installation. Just make sure to control which keys are imported by RPM as trusted and do not install packages with unknown signature.

But who is allowed (at "client" side) to accept a signature? How to enforce it?

Another issue is getting the list of signatures so that the company can include them, because openSUSE doesn't.

Neither of these is relevant for repository vs. RPM check. In both cases someone needs to trust key that is used for verification.

27.03.2018 17:46, Roger Oberholtzer пишет:

On Tue, Mar 27, 2018 at 4:30 PM, Andrei Borzenkov wrote:

...

Neither of these is relevant for repository vs. RPM check. In both cases someone needs to trust key that is used for verification.

An example on the white list (trusted) is Apple. How do they verify that you are really getting things from Apple? If there is a certificate, who verified it locally at the start?

Application in AppStore are signed by certificates issued by Apple. So you implicitly trust Apple to install valid root certificate on your system. Basically same with Microsoft.

I hears a rumor that all software will only be available from one of our servers. So perhaps they are planning on making local copies where they have a better chance of doing verification. I'm not sure that I like the sound of that. I cannot see our company mirroring all of openSUSE locally just for a few users. If, on the other hand, they could control the verification of the repo certificates when they are first accepted, perhaps they could allow download from the external repos.

This does not solve the problem of trusting source of local repo.

I think that the control of installing software will only be done for Windows. I don't think they will be able to do so for Linux. Which may present a problem...

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/27/2018 11:46 AM, Carlos E. R. wrote:

On 2018-03-27 09:25, Andrei Borzenkov wrote:

...

27.03.2018 09:39, Roger Oberholtzer пишет:

...

Is there a description of the idea/method behind the use of certificates to ensure that one (zypper?) is getting software from the real repository?

Where you get software from is more or less irrelevant for RPM based distribution. Each package is signed and signature is checked during installation. Just make sure to control which keys are imported by RPM as trusted and do not install packages with unknown signature. But who is allowed (at "client" side) to accept a signature? How to enforce it? You as the user, libzypp will ask you explicitely about keys it does not know if you want to trust  them always or temporarily. That usually happens when add a new repository.

All packages from a repository will always have the same signature iirc. All trusted keys are stored in the rpm database, you can list them with: rpm -qi "gpg-pubkey-*"

Another issue is getting the list of signatures so that the company can include them, because openSUSE doesn't.

-- Benjamin Zeller Systems Programmer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/28/2018 08:36 AM, Roger Oberholtzer wrote:

On Wed, Mar 28, 2018 at 8:16 AM, Benjamin Zeller wrote:

...

...

On 2018-03-27 09:25, Andrei Borzenkov wrote:

...

27.03.2018 09:39, Roger Oberholtzer пишет:

...

Is there a description of the idea/method behind the use of certificates to ensure that one (zypper?) is getting software from the real repository?

Where you get software from is more or less irrelevant for RPM based distribution. Each package is signed and signature is checked during installation. Just make sure to control which keys are imported by RPM as trusted and do not install packages with unknown signature. But who is allowed (at "client" side) to accept a signature? How to enforce it? You as the user, libzypp will ask you explicitely about keys it does not know if you want to trust

On 03/27/2018 11:46 AM, Carlos E. R. wrote: them always or temporarily. That usually happens when add a new repository.

And that is where our IT guys would have a question: how does each user know the key is correct? Well the IT can just accept only packages from the main repositories. There is normally no need to add new ones, especially for a office PC. Also why would a normal user have root access on the system? Since we are talking about a company here that wants to ensure security, the first step would be to not give the root password to every user, that means he or she can not add repositories or install software on their own.

And if the IT wants to give root rights to users, well they can just forget about controlling installed software completely. Same on Windows, if you give your user a Admin account he or she can do whatever.

How is this done by, say, Microsoft? Of course, they are perhaps only providing things from a limited number of places, so they can perhaps include the keys built in to the product?

IIRC they have a similar signing process, when you install software in windows you get asked if you want to trust it. However they do not have software repositories like a Linux distribution, you download the installers from some source and install it. Again, no normal user should do that on his own. IT would want to control whats running on the PCs.

openSUSE offer many repositories, including those set up by users. That is a more difficult thing to distribute, I guess.

Unofficial repositories is not what you'd want to use in you case. Only if your IT explicitely allows that. For example they could use a "Repository Index Service (RIS)" plugin with libzypp to serve a list of repositories, its a plugin for libzypp that allows a server to give a list of allowed repositories [1][2].

Given all the work that has gone in to the certificates in the openSUSE repos, one might guess that the next step could be making this work in a more controlled fashion. Do SUSE do something else with their products? Or is it assumed that the customer will get the right repo certificate when they add it?

You can already do this in a controlled fashion. When you first install openSUSE you get only the official repositories. The software there is hand picked, that means not just anyone can push packages there. When you add a repository you get asked to trust the key, and you will only be able to install packages signed by that key. No one else than the owner of the key can sign packages with it and the signature would be broken when you just flip one bit in the package so there is no room for changing a package without libzypp notifying it and rejecting the package. That is already pretty controlled and secure in my view ;). Benjamin [1] https://en.opensuse.org/openSUSE:Standards_Repository_Index_Service [2] https://doc.opensuse.org/projects/libzypp/HEAD/zypp-services.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

28.03.2018 09:36, Roger Oberholtzer пишет:

On Wed, Mar 28, 2018 at 8:16 AM, Benjamin Zeller wrote:

...

...

On 2018-03-27 09:25, Andrei Borzenkov wrote:

...

27.03.2018 09:39, Roger Oberholtzer пишет:

...

Is there a description of the idea/method behind the use of certificates to ensure that one (zypper?) is getting software from the real repository?

Where you get software from is more or less irrelevant for RPM based distribution. Each package is signed and signature is checked during installation. Just make sure to control which keys are imported by RPM as trusted and do not install packages with unknown signature. But who is allowed (at "client" side) to accept a signature? How to enforce it? You as the user, libzypp will ask you explicitely about keys it does not know if you want to trust

On 03/27/2018 11:46 AM, Carlos E. R. wrote: them always or temporarily. That usually happens when add a new repository.

And that is where our IT guys would have a question: how does each user know the key is correct?

How is this done by, say, Microsoft? Of course, they are perhaps only providing things from a limited number of places, so they can perhaps include the keys built in to the product?

That is exactly what happens during (open)SUSE installation - product key is part of medium and is imported in RPM database as trusted key.

openSUSE offer many repositories, including those set up by users. That is a more difficult thing to distribute, I guess.

Given all the work that has gone in to the certificates in the openSUSE repos, one might guess that the next step could be making this work in a more controlled fashion. Do SUSE do something else with their products? Or is it assumed that the customer will get the right repo certificate when they add it?

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer wrote:

On Wed, Mar 28, 2018 at 9:14 AM, Andrei Borzenkov wrote:

...

That is exactly what happens during (open)SUSE installation - product key is part of medium and is imported in RPM database as trusted key.

I seem to recall that the first time I run zypper, I am asked if I accept/trust the key for each repo.

Lately I have only been installing OEM images we make with KIWI. That I am certain asks this the first time. Perhaps that is a KIWI thing?

As to having root password: obviously one does not want to give this out.

If you were an IT department that had to manage > 13000 PCs running openSUSE, how would you automate keeping them up-to-date when the user could not do so? Same question for SUSE.

With salt, cfengine, puppet et al. -- Per Jessen, Zürich (7.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Mar 28, 2018 at 09:42:06AM +0200, Roger Oberholtzer wrote:

On Wed, Mar 28, 2018 at 9:14 AM, Andrei Borzenkov wrote:

...

That is exactly what happens during (open)SUSE installation - product key is part of medium and is imported in RPM database as trusted key.

I seem to recall that the first time I run zypper, I am asked if I accept/trust the key for each repo.

Lately I have only been installing OEM images we make with KIWI. That I am certain asks this the first time. Perhaps that is a KIWI thing?

As to having root password: obviously one does not want to give this out.

If you were an IT department that had to manage > 13000 PCs running openSUSE, how would you automate keeping them up-to-date when the user could not do so? Same question for SUSE.

We in that scope you will have some remote management capability, like for instance SUSE Manager to manage all those machines. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Mar 28, 2018 at 10:01 AM, Freek de Kruijf wrote:

Op woensdag 28 maart 2018 09:42:06 CEST schreef Roger Oberholtzer:

...

On Wed, Mar 28, 2018 at 9:14 AM, Andrei Borzenkov wrote:

...

That is exactly what happens during (open)SUSE installation - product key is part of medium and is imported in RPM database as trusted key.

I seem to recall that the first time I run zypper, I am asked if I accept/trust the key for each repo.

Lately I have only been installing OEM images we make with KIWI. That I am certain asks this the first time. Perhaps that is a KIWI thing?

As to having root password: obviously one does not want to give this out.

If you were an IT department that had to manage > 13000 PCs running openSUSE, how would you automate keeping them up-to-date when the user could not do so? Same question for SUSE.

Interesting options I did not know about. In my situation, the IT department will not offer to manage the openSUSE machines we have in our department. I am worried that they will not let them connect to the internal network. Or at least not in a way that they can access anything other than the outside network, as is allowed for guests. No access to shared drives or internal web stuff. I am expecting long discussions. And they are a very Windows-centric group. Sigh. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 28 Mar 2018 11:08:49 +0200 Roger Oberholtzer wrote:

On Wed, Mar 28, 2018 at 10:01 AM, Freek de Kruijf wrote:

...

Op woensdag 28 maart 2018 09:42:06 CEST schreef Roger Oberholtzer:

...

On Wed, Mar 28, 2018 at 9:14 AM, Andrei Borzenkov wrote:

...

That is exactly what happens during (open)SUSE installation - product key is part of medium and is imported in RPM database as trusted key.

I seem to recall that the first time I run zypper, I am asked if I accept/trust the key for each repo.

Lately I have only been installing OEM images we make with KIWI. That I am certain asks this the first time. Perhaps that is a KIWI thing?

As to having root password: obviously one does not want to give this out.

If you were an IT department that had to manage > 13000 PCs running openSUSE, how would you automate keeping them up-to-date when the user could not do so? Same question for SUSE.

Interesting options I did not know about.

In my situation, the IT department will not offer to manage the openSUSE machines we have in our department. I am worried that they will not let them connect to the internal network. Or at least not in a way that they can access anything other than the outside network, as is allowed for guests. No access to shared drives or internal web stuff.

If their assumption is that there are no hostile machines on their network then their security is very brittle, especially if there's anything like 13000 machines. Access to file servers and other services should be managed by a system that doesn't care where (i.e. what OS) the request is coming from, only that where it comes from has the appropriate tokens, issued by their own control systems.

I am expecting long discussions. And they are a very Windows-centric group.

Sigh.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Mar 28, 2018 at 1:48 PM, Dave Howorth wrote:

Access to file servers and other services should be managed by a system that doesn't care where (i.e. what OS) the request is coming from, only that where it comes from has the appropriate tokens, issued by their own control systems.

Indeed. But they said that there were some couple of thousand computers that were infected with a virus last year. They want to stop this. I guess their security will be simply not letting people do things. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Mar 28, 2018 at 2:12 PM, Knurpht @ openSUSE wrote:

And right they are, but it's not enough. I've seen it happen live at a customer's ( I built, host and maintain their webapp ) office. One person opens an email, computer behaves weird, so the user reboots, to end up with a locked system, and within a minute all other Windows machines were caught. The very same day the local news channels started about WannaCry. Took two days to re-setup every individual machine. The originating email was infected at one of their customers' computers.

That is where it really gets tricky. IT cannot control our customers. And they cannot say that we cannot share documents with them. It's a part of what we do... -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

28.03.2018 09:16, Benjamin Zeller пишет:

On 03/27/2018 11:46 AM, Carlos E. R. wrote:

...

On 2018-03-27 09:25, Andrei Borzenkov wrote:

...

27.03.2018 09:39, Roger Oberholtzer пишет:

...

Is there a description of the idea/method behind the use of certificates to ensure that one (zypper?) is getting software from the real repository?

Where you get software from is more or less irrelevant for RPM based distribution. Each package is signed and signature is checked during installation. Just make sure to control which keys are imported by RPM as trusted and do not install packages with unknown signature. But who is allowed (at "client" side) to accept a signature? How to enforce it? You as the user, libzypp will ask you explicitely about keys it does not know if you want to trust  them always or temporarily. That usually happens when add a new repository.

All packages from a repository will always have the same signature iirc.

I do not think there is any rule on it (it is just side effect of how OBS works). The repository metadata includes packages hashes; if you decide to trust repository metadata signature, zypper will skip (or probably ignore, because I still get warnings) verification of RPM themselves, so you can really put anything, including unsigned RPM or RPM signed by different keys. If you add unsigned repository zypper will enforce package signature check and will fail installation if key is not known to RPM. You trust signed repository not because "all packages have the same signature" but because signed repository includes signed hashes of its content which is verified by zypper.

All trusted keys are stored in the rpm database, you can list them with: rpm -qi "gpg-pubkey-*"

...

Another issue is getting the list of signatures so that the company can include them, because openSUSE doesn't.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org