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 <[EMAIL PROTECTED]>
Project Manager Contracts, Migration, SDK
Novell, Linux R&D Nuernberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
