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.

From May 30th to July 4th we had a YaST workshop in Nuremberg. The workshop was basically a hackshop as we wanted to work on cool and new things for YaST during this week.

There is one big change in YaST in openSUSE 11.0 - yea, we found out that there are even more colors than gray, ok - but there is one that is not really visible to the end-user. Stefan Hundhammer, maintainer our YaST UI, completely separated the UI from the rest of the YaST infrastructure. This now makes it possible to use the UI directly, from anywhere, independent from our YaST-own-language YCP. So with a team of four hackers we wanted to prove that we can write a YaST module in plain C++ using the new modularized UI directly. And here is the outcome:

We went for rewriting the registration module (well, we chose it because I know it well, as I am the maintainer, and it will change anyhow for the next release). This module is not that integrated in the overall YCP world, so it should be feasible. First we had to find an alternative way to access system configuration files, as this is done by so-called SCR agents in YCP. To make life easier (and future development faster) we had to look for a replacement of our YCP Wizard Seqencer. And of course we redesigned all dialogs to make them more intuitive.

We solved all the issues and now have

• a wrapper class for accessing different configuration files (currently only ini files)
• an automatic wizard sequencer equivalent (using the advantages of an object oriented language, btw YCP is not)
• three clear and intuitive dialogs, every user should understand

And as everybody wants to see screenshots, here they are:

The code is just a proof of concept and not yet reusable for new YaST modules but everything we wanted to show works great. We will continue to work on such kind of modules and in that process move the generic parts out into single libraries so that they can be reused and even may be exposed to scripting languages.

Writing YaST module this way has lots of advantages

• YaST modules evolved into the object oriented world and can make use of it (the automatic sequencer is the first benefit)
• the code is reusable
• a huge bunch of documentation and lots of tools exist for C++
• its a compiled language and has a better performance than an interpreted one
• we can bind automatically to the most important scripting languages and give them access to the modules logic

If you are interested in the source code, have a look at my svn repo and if you want to help join the team and contact us on our mailinglist.

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.

You run Linux already but want to install 11.0? DVD image takes too long to download? Don’t want to waste a CD for the mini iso? A router connects you to the internet?

Check out setupgrubfornfsinstall. It’s a dialog based shell script to prepare remote network installations. It was primarily made for use in LANs but now also supports direct installation from opensuse.org. Just run the script, select 11.0 and it will download the kernel and initrd used for installation. After that it adds an entry to your boot loaders’ config file with proper parameters. Reboot, select the new entry and the installation starts.

[PS. I coudn't resist. I just had to name the package '*Kit'. ]

Need to do a firmware update with a DOS program?

Can get tricky if you don’t have a DOS system around. We used to provide a bootable floppy image for that in the past (package dosbootdisk). But who has a floppy drive anyway?

So, here comes the new
FirmwareUpdateKit package. Install it and run run, e.g. fuk --grub foobar.exe That’s it. The next reboot gives you the option to start DOS and run foobar.exe.

fuk can also create bootable ISOs and, of course, even floppy images.

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

Quite often I get bugreports that the hardware detection doesn’t find the monitor. Well, what should I do? We run a Video BIOS function for it, and if the BIOS can’t see the monitor, we’re out of luck.

But maybe not? It can well be that running BIOS code in Linux is not the best idea either.

To shed some light I wrote a small (6.5k if you must know) DOS-program and put it on a bootable CD. If that can’t detect the monitor it’s probably the BIOS’s fault, if it works blame, well, someone else.

On a side note, the program was created with the usual gcc. It’s really surprising what you can do with a nice include file and a linker script.

We are redesigning the YaST Expert Partitioner for openSUSE 11.1 and SLE11. The main idea is to have a navigation tree with all available storage devices on the left side and to display information on the right side along with buttons to perform appropriate actions. See the screenshot.

RPMs are available in the openSUSE Build Server in the repository home:aschnell. They are far from finished by you can already navigate in the tree and inspect you storage system. It should be possible to see where we are heading with the redesign. You can install them on your openSUSE 11.0 Beta 3.

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.