There has been a report (with further information at this page and at the FAQ) looking at package management security on various distributions that IMO was rather condensed in its summary report and therefore raised some false alarms for various distributions including openSUSE.

Ludwig, one of our security experts, sent out a mail with a reaction to the report and I’d like to point out some of the things from the report and how it’s handled in the openSUSE 11.0 distribution.

Let me state first the major lines of defense that openSUSE uses:

• Package downgrade is not possible, YaST will not do this automatically and therefore many of the attacks (installing an old and vulnerable package) are not possible.
• The openSUSE download redirector serves the metadata from a known and trusted source.  I advise everybody to use the download redirector via http://download.opensuse.org.
• The openSUSE updates have both cryptographically signed packages and cryptographically signed meta data - and YaST check these signatures and reject files that do not match the signature.

The described attacks are:

• “Replay Attack: Metadata Replay”: Not possible since the openSUSE download redirector serves the metadata from a central location.  The only chance here would be a man-in-the-middle attack but this would not help since YaST will not do a package downgrade.
• “Replay Attack:Mirror Control”: Yes, it’s easy to become an openSUSE mirror but this will not degrade your security since the metadata comes from the download redirector and we only redirect to mirrors that contain the right version of a package - and the redirector monitors that the mirrors contain the right files.  YaST is designed with mirrors going out of date or getting corrupted in mind.
• Attacks called “Extraneous Dependencies”, “Unsatisfiable Dependencies”, “Provides Everything” on the other attacks page: Let me cite the page where it mentions protection against these attack: “The easiest way is to use a package manager that signs the repository metadata (like APT or YaST)”.
• “Endless Data Attack”: This is basically a denial of service attack which the admin will soon notice and can then take appropriate action.  It cannot happen for metadata since those come from the download redirector but it could happen with openSUSE for packages since we do download the complete file and do not use the file size information contained in the metadata yet.  This is something we plan to address for our next release.

Note that when I speak about YaST I mean everything that uses the openSUSE package management library libzypp which includes YaST, zypper and the updater applets.

Note also that the FAQ has a question about the download redirector: “Q: What about OpenSUSE’s download redirector? Does it increase or decrease my security? A: OpenSUSE’s download redirector increases the user’s security…”.  I’d like to thank Christoph Thiel, Marcus Rückert and Peter Pöml for their work over the years on the redirector.  Peter is the current maintainer and did the last rewrite including the serving of metadata.

Note: if you use SUSE Linux enterprise products, then only servers owned by Novell are used via secure https connections which avoid all these attacks.

Our package management and security experts have been reviewing and improving the security aspects of the package management stack continuously - and the report shows that they were successfull.

In order to give an answer about “Why this package will be installed and who needs it?” I have added a new Dialog in the QT single package selector:

Select one item (pattern, package) in the single selection frame, use the right mouse button and select “Show solver information”. A solverrun will be made for this item and the result will be shown with this dialog.

• Black arrow : This item will be required by….
• Green arrow: This item will be recommended by…
• Green boxes: This package is already installed
• Grey boxes: This package will be installed
• Blue boxes: Patterns

You can navigate through the tree via the overview frame:

After you have selected one item in the tree you can see more information about:

e.G. this item will install two further patterns due to the shown dependencies.

In order to decrease the complexity of the tree you can blind out:

• already installed packages
• recommended packages/patterns

So you will get a shrinked tree:

Technical Background:

This is a simple Qt Dialog widget which can be used in other programs too. ( Package libqdialogsolver1)

YaST uses this widget as a YaST plugin. So if this package is not available you will get a popup in single selection only.

It would be nice if libzypp had some framework that allowed to implement extensions like e.g. a history of installed and  removed packages easily.

I’m currently looking into the boost signals library to see if we could use it to provide hooks for such extensions.

A  future  ZYpp::commit would then emit signals e.g. before and after installation/deletion of packages. Some extension code could then connect to those signals to create e.g. such a history.

Another candidate would be the repository management emitting signals as repositories are added removed refreshed.

There is some work going on to put installation source creation functionality into kiwi.
At the moment kiwi can use prepared installation sources such as:

• BuildService Repositories
• mounted DVDs
• FTP trees

But what if you have a local Build Service building some binary only packages and you wish tp make a installable media set from, say, “SLES + binary only drivers”?
You can use the inter-BS-Connectivity feature to only build the drivers (and not the whole distribution) in your BS and then create an installation source from your main BS project.

This is possible since release of the package kiwi-instsource which extends the functionality of the config.xmlfile to allow the compilation of an installation source from scratch.
Hereby “scratch” means directories containing .rpm and .spm files. Of course some information must be provided for the metadata creation — but this is also all in the config file (with one known exception — the PDB data).

The rest is figuring out which packages must be on the installation source.
Since it is perfectly ok to have conflicting packages in instsources, there is no dependency check or package resolving in this stage. The information must come from the user.

Therefore the package list may become rather long and I already plan to implement some simplification.
These plans include:

• allowing more than one <repopackages> section
• implement outsourcing blocks in separate files using XML functionality

Duncan has done quick some measurements comparing zypper, yum and smart which show that zypper - the command line tool that openSUSE uses for package management - is now (finally not only comparable to yum and smart but even faster.

I would be very interested if somebody would do some extensive benchmarking to see whether zypper is faster overall and handles the corner causes as well.

Just compare: Setup for installation with yum is 19s whereas zypper needs 10s. Creation of meta data caches needs 4 minutes with yum and zypper rocks with 18s.

Memory usage: zypper needs maximal a bit over 18 MB while yum needs more than 180 MB and smart more than 60 MB.

If you run zypper - or the package management GUI applications, you really see that the team has done a great job to speed up and use less memory than before.