Re: [opensuse-factory] SUSE-Linux10.1-Beta9-Extra problems
Hi all! Andreas Jaeger asked me to jump in and say a few words on the metadata signing we have added recently to make remote (and potentially insecure) installation and update sources more secure to use. Marcus Meißner has posted a short answer a few minutes ago. Here is the long version:
First of all, it looks like the non-OSS software repository for opensuse beta9 isn't setup right.
ftp://ftp.suse.com/pub/suse/install/10.1/SUSE-Linux10.1-Beta9-Extra/
It looks more like a bug in YaST, please create a bugreprot against YaST with log files attached,
Could this be related to the checking with the content.key? If yes, how is the content.key calculated? On what is it based? (Perhaps people killfiled the makeSUSEdvd thread, so I ask here again) Could we get any info on this security thing, or is is security through obscurity?
No, this is all "public" security using GPG with public/private keys. The only thing we will not publish, for obvious reasons, are the private keys we use. ;-)
PS. The reason I ask is because the OP talks about the difference being that there is a content.key in Beta9. houghi
That's right.
I'll briefly outline the metadata and package signing concept for SUSE Linux
10.1 and beyond:
We use detached GPG signatures to sign the most important metadata files in an
installation source/repository.
There are two flavours of installation sources that I'll cover:
1) "Classic" SUSE-style installation sources
This is what we are using on the installation media. There are two entry
points:
a) The file "media.1/products"
This file lists the absolute paths (absolute from the root of the installation
source file tree) to the products on a media. This is interesting for
multi-product media. But usually there is only one line, e.g.
"/ SUSE-Linux-Enterprise-Desktop 10"
This file will be signed with a SUSE key on all products coming from SUSE. The
public key (GPG public key, ascii armor protected) for this key that can be
used to verify the signature is in the file "products.key" for convenience.
This key will also be imported from the initrd (the initial bootable Linux
image that always starts first if you run an installation media), so usually
YaST will already know about it. This is not the case yet on the current
betas. The initial key is the one YaST always trusts without asking. The key
is usually also on the installation media as
/gpg-pubkey-9c800aca-40d8063e.asc
(This key may change. The one above is the one we currently use.)
The signature for "products" is in the file "products.asc".
When YaST detects an installation source it checks if the file "products" is
there, and then checks if it is signed with a known key. If it is not signed
at all or with an unkown key, or if the key is on the media, but not trusted
(yet), the user will be asked what to do.
We sign the "products" file to make sure that nobody can add products to an
installation source that don't belong there.
b) The file "content"
For every product there is a "content" file. If there is no "products" file
that tells us where the products are, we look for the file in the
installation source's root.
The "content" file is signed in the same style as the "products" file, so
there is a "content.key" (usually, but not necessarily the same as
"products.key").
Compared to "content" files on older releases we have additional data. There
are two new keys: META and KEY. Here are two examples:
META SHA1 08579e4b28287d6aedd954098b64c6bb49d17367 packages
KEY SHA1 a108c6aab19fe604fa98ef299cdce6e6ba275f09
gpg-pubkey-0dfb3188-41ed929b.asc # all in one line
META keys are added for all files in the directory named in the key DESCRDIR,
e.g.
DESCRDIR suse/setup/descr
on a typical SUSE Linux.
Before YaST uses any file from DESCRDIR it will look up the entry in
"content". This entry is currently an SHA1 checksum followed by the package
name. This may change to an SHA256 checksum.
The KEY entries list all the keys that YaST should import from the media.
Those keys can be used for checking RPM signatures and metadata signatures
and will be stored in he RPM database, so they can be used with "rpm
--checksig" for package-level verification.
If I get things right, we will also trust those by default because the list of
KEYs is in a file that was signed by the initial key from the initrd that we
trust by default.
The next step in the chain is the file "packages" in DESCRDIR.
If you are familiar with its syntax you will see that we added a new tag
there, too, right after the "Pgk:" tag. Here is an example of the first two
lines of the entry for the default kernel:
=Pkg: kernel-default 2.6.16 13 i586
=Cks: SHA1 8c8eb2b605e1d626c22bea8dd0c3b05885432b16
Again we have an SHA1 checksum.
So there is a consistent chain of trust from the initial key (that you need to
verify on your own if you don't trust your installation media) via the
"product" and "content" files to the individual packages. The chain makes
sure that all those files belong there and haven't been manipulated.
On the package level we may or may not perform an additional "rpm --checksig".
2) The "repomd" or "YUM" format
Here we use the same basic concept. The initial file is "repomd.xml", which is
again signed with a detached GPG signature in "repomd.xml.asc".
I don't know right now if there is a default place for the public key, but
usually repomd repositories will be used for udpates and as an add-on source,
so the keys are known to the the system already.
In repomd.xml and all the files referenced from there, a <checksum> tag again
makes sure that the installation/update source is consistent. Here is an
example snippet:
<data type="patches">
<location href="repodata/patches.xml"/>
<checksum type="sha">90ac427749079973d044a9398d6749f5f008</checksum>
<timestamp>1144088097</timestamp>
<open-checksum type="sha">90ac4044a9398d6749f5f008</open-checksum>
</data>
repomd uses those checksums by default. The only thing we added is signing the
"repomd.xml" file.
So much for the conceptual background. Feel free to comment on the concept if
you have any questions/concerns.
Now for the problems with YaST and installation sources you may have faced in
the last couple of days:
The problem is that the signature checks are already in place, but the GUI and
command line options that let you import non-SUSE keys, override key checking
and integrity checking are not in place yet.
With the final product you will be able to switch all the checks off, so you
can still use sources that do not use any signing or checksums. But currently
there are a few bugs with YaST expecting a signature to be there etc.
We will also provide tools for setting up your own signed and checksum-enabled
installation sources ASAP.
I'll keep you posted and will try to answer your questions. If you want to put
this information onto opensuse.org, I wouldn't object. ;-)
I'll try to update opensuse.org on my own as soon as possible, too.
Cheers
Joachim
--
Joachim Werner
On Tue, Apr 04, 2006 at 02:29:58PM +0200, Joachim Werner wrote: <snip great explanation>
Now for the problems with YaST and installation sources you may have faced in the last couple of days:
The problem is that the signature checks are already in place, but the GUI and command line options that let you import non-SUSE keys, override key checking and integrity checking are not in place yet.
OK. That was what I figured out eventually. ;-)
With the final product you will be able to switch all the checks off, so you can still use sources that do not use any signing or checksums. But currently there are a few bugs with YaST expecting a signature to be there etc.
Somehow I managed to work around that and get non-signed RPM's on a iso. This with just editing the content of one file. This means that even though people think they have the real deal, they might get an infected CD or DVD. Does this then not kill of the purpose of the signing? It makes it possibe to get insecure things installed. All it does is remove the ^META and ^KEY from ./content. Don't get me wrong, I understand the need for signing, as long as there is way around it for those who want it (at their own risk) Thanks for the clear explanation. I will re-read it and might come back with extra questions later. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
On Tue, Apr 04, 2006 at 03:23:56PM +0200, houghi wrote:
On Tue, Apr 04, 2006 at 02:29:58PM +0200, Joachim Werner wrote: <snip great explanation>
Now for the problems with YaST and installation sources you may have faced in the last couple of days:
The problem is that the signature checks are already in place, but the GUI and command line options that let you import non-SUSE keys, override key checking and integrity checking are not in place yet.
OK. That was what I figured out eventually. ;-)
With the final product you will be able to switch all the checks off, so you can still use sources that do not use any signing or checksums. But currently there are a few bugs with YaST expecting a signature to be there etc.
Somehow I managed to work around that and get non-signed RPM's on a iso. This with just editing the content of one file. This means that even though people think they have the real deal, they might get an infected CD or DVD.
Does this then not kill of the purpose of the signing? It makes it possibe to get insecure things installed. All it does is remove the ^META and ^KEY from ./content.
No, since we also sign the Packages / repomd.xml files and these contain the SHA-1 / SHA-256 sums of the packages. Ciao, Marcus
On 4 Apr 2006 at 14:29, Joachim Werner wrote: [...]
This file will be signed with a SUSE key on all products coming from SUSE. The public key (GPG public key, ascii armor protected) for this key that can be used to verify the signature is in the file "products.key" for convenience.
This key will also be imported from the initrd (the initial bootable Linux image that always starts first if you run an installation media), so usually YaST will already know about it. This is not the case yet on the current
I see no real advantage having the key in initrd (other than security by obscurity): Anyone wanting to intoduce his own key can do so either in the root filesystem (instsys) or initrd.
betas. The initial key is the one YaST always trusts without asking. The key is usually also on the installation media as
See above.
/gpg-pubkey-9c800aca-40d8063e.asc
(This key may change. The one above is the one we currently use.)
The signature for "products" is in the file "products.asc".
When YaST detects an installation source it checks if the file "products" is there, and then checks if it is signed with a known key. If it is not signed at all or with an unkown key, or if the key is on the media, but not trusted (yet), the user will be asked what to do.
We sign the "products" file to make sure that nobody can add products to an installation source that don't belong there.
But that user could replace the key and possibly re-sign the packages, or could modify the signature checkingof yast a bit (or use an older version of gpg) ;-)
b) The file "content"
For every product there is a "content" file. If there is no "products" file that tells us where the products are, we look for the file in the installation source's root.
The "content" file is signed in the same style as the "products" file, so there is a "content.key" (usually, but not necessarily the same as "products.key").
Compared to "content" files on older releases we have additional data. There are two new keys: META and KEY. Here are two examples:
META SHA1 08579e4b28287d6aedd954098b64c6bb49d17367 packages
KEY SHA1 a108c6aab19fe604fa98ef299cdce6e6ba275f09 gpg-pubkey-0dfb3188-41ed929b.asc # all in one line
META keys are added for all files in the directory named in the key DESCRDIR, e.g.
DESCRDIR suse/setup/descr
on a typical SUSE Linux.
Before YaST uses any file from DESCRDIR it will look up the entry in "content". This entry is currently an SHA1 checksum followed by the package name. This may change to an SHA256 checksum.
The KEY entries list all the keys that YaST should import from the media. Those keys can be used for checking RPM signatures and metadata signatures and will be stored in he RPM database, so they can be used with "rpm --checksig" for package-level verification.
If I get things right, we will also trust those by default because the list of KEYs is in a file that was signed by the initial key from the initrd that we trust by default.
The next step in the chain is the file "packages" in DESCRDIR.
If you are familiar with its syntax you will see that we added a new tag there, too, right after the "Pgk:" tag. Here is an example of the first two lines of the entry for the default kernel:
=Pkg: kernel-default 2.6.16 13 i586 =Cks: SHA1 8c8eb2b605e1d626c22bea8dd0c3b05885432b16
Again we have an SHA1 checksum.
So there is a consistent chain of trust from the initial key (that you need to verify on your own if you don't trust your installation media) via the "product" and "content" files to the individual packages. The chain makes sure that all those files belong there and haven't been manipulated.
On the package level we may or may not perform an additional "rpm --checksig".
2) The "repomd" or "YUM" format
Here we use the same basic concept. The initial file is "repomd.xml", which is again signed with a detached GPG signature in "repomd.xml.asc".
I don't know right now if there is a default place for the public key, but usually repomd repositories will be used for udpates and as an add-on source, so the keys are known to the the system already.
In repomd.xml and all the files referenced from there, a <checksum> tag again makes sure that the installation/update source is consistent. Here is an example snippet:
<data type="patches"> <location href="repodata/patches.xml"/> <checksum type="sha">90ac427749079973d044a9398d6749f5f008</checksum> <timestamp>1144088097</timestamp> <open-checksum type="sha">90ac4044a9398d6749f5f008</open-checksum> </data>
I think there is a slight difference between "SHA" and "SHA-1" ;-)
repomd uses those checksums by default. The only thing we added is signing the "repomd.xml" file.
So much for the conceptual background. Feel free to comment on the concept if you have any questions/concerns.
Now for the problems with YaST and installation sources you may have faced in the last couple of days:
The problem is that the signature checks are already in place, but the GUI and command line options that let you import non-SUSE keys, override key checking and integrity checking are not in place yet.
With the final product you will be able to switch all the checks off, so you can still use sources that do not use any signing or checksums. But currently there are a few bugs with YaST expecting a signature to be there etc.
Should be an option for software installer / YOU ("only accept digitally signed software/updates" where the user should be able to review his trusted keys)
We will also provide tools for setting up your own signed and checksum-enabled installation sources ASAP.
I'll keep you posted and will try to answer your questions. If you want to put this information onto opensuse.org, I wouldn't object. ;-)
I'll try to update opensuse.org on my own as soon as possible, too.
Cheers
Joachim
Thanks. Regards, Ulrich
Hi Ulrich, Am Mittwoch, 5. April 2006 08:03 schrieb Ulrich Windl:
This key will also be imported from the initrd (the initial bootable Linux image that always starts first if you run an installation media), so usually YaST will already know about it. This is not the case yet on the current
I see no real advantage having the key in initrd (other than security by obscurity): Anyone wanting to intoduce his own key can do so either in the root filesystem (instsys) or initrd.
The boot process during installation is two-step. First, syslinux (or one of its siblings like pxelinux ) loads an initial mini-Linux (from the files "linux" and "initrd") that then loads the image from the file "root", which can already be on a remote installation source. This is for a typical i386/x86-64 system. Things vary a bit on other architectures. So, to make things really secure, the files used to boot into the first step (linux, initrd, and maybe also syslinux/pxelinux) will have to be trusted. E.g. you'll have to get them from a trusted channel or download them from an untrusted source and verify the checksums and/or signatures using a key you got from a trusted channel. Then we can have a public key in the initrd that can be used to verify the root image, which either gets passed the initial public key from the first installation step or comes with its own one (which could well be different). I'm not sure if all of this will be in place for SUSE Linux 10.1 (probably not), but if it was, would you still see a possibility of breaking the security chain? Always provided that the first step can be trusted ...
betas. The initial key is the one YaST always trusts without asking. The key is usually also on the installation media as
See above.
/gpg-pubkey-9c800aca-40d8063e.asc
(This key may change. The one above is the one we currently use.)
The signature for "products" is in the file "products.asc".
When YaST detects an installation source it checks if the file "products" is there, and then checks if it is signed with a known key. If it is not signed at all or with an unkown key, or if the key is on the media, but not trusted (yet), the user will be asked what to do.
We sign the "products" file to make sure that nobody can add products to an installation source that don't belong there.
But that user could replace the key and possibly re-sign the packages, or could modify the signature checkingof yast a bit (or use an older version of gpg) ;-)
If the Linux system you use for accessing the installation source is trusted (the most common case of this is that you use original installation media), how should an attacker successfully do that? The attacker can replace the key, but that key will not be trusted, unless the user accepts it He can not re-sign packages with the SUSE private key because he doesn't have it, and if the installing user does not accept the attacker's key, his signed packages will not be used. The signature-checking of yast and the GPG version used are both under control of the trusted system, which does prevent accidentally installing untrusted replacements of those tools. So I only see two possibilities of breaking the security chain: a) The root user on the machine installs software that disables/manipulates one of the tools or libraries used. b) An attacker does that using a root exploit. Both cases are beyond the scope of this effort. As soon as we have a stupid admin or a root exploit, we are doomed anyway.
In repomd.xml and all the files referenced from there, a <checksum> tag again makes sure that the installation/update source is consistent. Here is an example snippet:
<data type="patches"> <location href="repodata/patches.xml"/> <checksum type="sha">90ac427749079973d044a9398d6749f5f008</checksum> <timestamp>1144088097</timestamp> <open-checksum type="sha">90ac4044a9398d6749f5f008</open-checksum> </data>
I think there is a slight difference between "SHA" and "SHA-1" ;-)
Checksums that have the type="sha" (as opposed to "md5" in repomd files are SHA-1 checksums. They do not use the original (now considered insecure) SHA.
With the final product you will be able to switch all the checks off, so you can still use sources that do not use any signing or checksums. But currently there are a few bugs with YaST expecting a signature to be there etc.
Should be an option for software installer / YOU ("only accept digitally signed software/updates" where the user should be able to review his trusted keys)
The default will be secure (at least on the enterprise products based on SUSE
Linux), but this can be switched off per installation source.
The user can review the keys when he imports them. We plan a "key management"
interface for later, so you can get rid of a key again, using a UI.
The keys are imported into the RPM database, so an advanced user can always
import or erase keys directly.
Cheers
Joachim
--
Joachim Werner
On 5 Apr 2006 at 20:42, Joachim Werner wrote: [...] Thanks for explaining. I did not consider a "split installation" (local boot with remote repository).
<data type="patches"> <location href="repodata/patches.xml"/> <checksum type="sha">90ac427749079973d044a9398d6749f5f008</checksum> <timestamp>1144088097</timestamp> <open-checksum type="sha">90ac4044a9398d6749f5f008</open-checksum> </data>
I think there is a slight difference between "SHA" and "SHA-1" ;-)
Checksums that have the type="sha" (as opposed to "md5" in repomd files are SHA-1 checksums. They do not use the original (now considered insecure) SHA.
What I mean to say is: Shouldn't ``type="sha1"'' be used instead? Regards, Ulrich P.S. Unable to get any mirror server for 10.0 YOU for several minutes here. Known problem?
Hi!
<data type="patches"> <location href="repodata/patches.xml"/> <checksum type="sha">90ac427749079973d044a9398d6749f5f008</checksum> <timestamp>1144088097</timestamp> <open-checksum type="sha">90ac4044a9398d6749f5f008</open-checksum> </data>
I think there is a slight difference between "SHA" and "SHA-1" ;-)
Checksums that have the type="sha" (as opposed to "md5" in repomd files are SHA-1 checksums. They do not use the original (now considered insecure) SHA.
What I mean to say is: Shouldn't ``type="sha1"'' be used instead?
Yes, it should. But we didn't write that part of the YUM format, so we have to keep "sha" to stay compatible for now. ;-)
Regards, Ulrich P.S. Unable to get any mirror server for 10.0 YOU for several minutes here. Known problem?
Is this fixed now?
Cheers
Joachim
--
Joachim Werner
On 7 Apr 2006 at 13:11, Joachim Werner wrote:
P.S. Unable to get any mirror server for 10.0 YOU for several minutes here. Known problem?
Is this fixed now?
Since yesterday afternoon somewhat (I don't know exactly, because I had a meeting) Regards, Ulrich
participants (4)
-
houghi -
Joachim Werner -
Marcus Meissner -
Ulrich Windl