Thursday, June 01, 2006

Nvidia driver hack for Xen kernel - SUSE 10.1

I've been wrestling with Xen for a week or so now but before I post some articles about Xen itself I'd like to share this quick hack to get the Nvidia binary driver working with the SUSE 10.1 Xen kernel.

While the 'nv' driver is excellent it's nice to have all the features of my hardware available, even if unfortunately it means using a blob driver from Nvidia. Also the nv driver doesn't seem to probe my monitor using EDID and seems to use more generic modes. This means that while overall image quality is excellent, the DPI is wrong for my hardware and so I have to tweak font sizes and such things. It may be possible to fix this by using custom modelines in my xorg.conf, or to force the nv to probe my screen using EDID but for that amount of effort I may as well get the Nvidia driver working.

Anyway, here's the hack to get the latest Nvidia driver ( 8762 as I write this ) working with the Xen kernel. It should work for x86_64 also but I only tested it for x86. Props to JaXXon on the forums for the original FC patch.

Run this shell script as root from the same location as the Nvidia driver package.

# Quick n' dirty nvidia hack for kernel-xen
# REF:
# Tested for kernel-xen ( SUSE 10.1 - x86 ) using nvidia 1.0-8762

REQUIRED_PACKAGES="kernel-source kernel-xen gcc make glibc-devel module-init-tools gzip wget binutils"
SYSTEM_ARCH=`uname -m`

function error_die {
echo -e "ERROR: $*" >&2;
exit 1;

# Check for root, architecture and runlevel
[ "$UID" = "0" ] || error_die "Please run this script as root"
ps -C X &>/dev/null && die "Your X server is currently running, please run this script from runlevel 3"
case $(uname -m) in
x86_64) NV_ARCH=x86_64 ;;
i?86) NV_ARCH=x86 ;;
*) error_die "Architecture not supported: $SYSTEM_ARCH"

# Check user has basic packages installed
echo -n "Checking installed packages"
for package in $REQUIRED_PACKAGES; do
rpm -q "$package" &>/dev/null || missing="$missing $package"
echo -n "."
if [ -n "$missing" ]; then
echo -e "ERROR:\nThe following package(s) is/are missing:" >&2
for m in $missing; do
echo " $m" >&2
echo >&2
echo "Please install these packages then run this script again" >&2
exit 1

# Extract the driver package, assuming it exists
./NVIDIA-Linux-$NV_ARCH-1.0-$ --extract-only --target /tmp/NV-$NV_VERSION || error_die "Failed to extract the driver package NVIDIA-Linux-$NV_ARCH-1.0-$, please check this file exists and try again"

# Fetch the patch and apply
echo -e "Retrieving nvidia patch..."
wget "" &>/dev/null || error_die "Failed to download the nvidia driver patch"
mv "attachment.php?attachmentid=17583&d=1145325458" /tmp/NV-$NV_VERSION/patch-nv-8762.diff
cd /tmp/NV-$NV_VERSION/usr/src/nv
patch -p1 < /tmp/NV-$NV_VERSION/patch-nv-8762.diff

# Build precompiled module
make nv-linux.o mkprecompiled --interface=nv-linux.o --output=nv-linux.o-1.0-$NV_VERSION.suse-10.1-$KERNEL_XEN_VERSION \
--description="Quick n dirty for kernel-xen" \
--proc-version="`cat /proc/version`" \
--major=1 --minor=0 --patch=$NV_VERSION
mv nv-linux.o-1.0-$NV_VERSION.suse-10.1-$KERNEL_XEN_VERSION precompiled/

# Insert missing symbols
for sym in xen_tlb_flush force_evtchn_callback xen_features; do
export $sym=$(egrep " $sym\$" $SYMBOL_MAP | colrm 9)
ld -m elf_i386 --defsym xen_tlb_flush=0x$xen_tlb_flush \
--defsym force_evtchn_callback=0x$force_evtchn_callback \
--defsym xen_features=0x$xen_features \
-r -o nvidia.ko nvidia.o nvidia.mod.o

# Install other required NVIDIA binaries
echo "Installing NVIDIA driver support binaries"
cd /tmp/NV-$NV_VERSION
./nvidia-installer --silent --no-kernel-module

# Install and load the module
cp usr/src/nv/nvidia.ko "/lib/modules/$KERNEL_XEN_VERSION/kernel/drivers/video"
echo "Installing NVIDIA driver kernel module"
modprobe nvidia || die "ERROR: Failed to load the NVIDIA kernel module"
rm -Rf /tmp/NV-$NV_VERSION
echo "Success!"

Additional Help

Additional help for SUSE Linux 10.1 can be found on the mailing lists or alternatively you can drop by the IRC chat channel #suse on freenode IRC network. If you are using KDE in SUSE Linux 10.1 then the IRC chat client Konversation is already configured to connect to the #suse channel on freenode IRC network.

Friday, May 19, 2006

Securing Applications With AppArmor - SUSE 10.1

This week I'm going to take a look at making your PC workstation more secure by configuring AppArmor to work with some common applications. First though a little foreword about computer security.

Unfortunately computer security is rarely out of the news these days. If it's not the anti-virus companies trying to foster a climate of fear with portents of doom about the next trend in virus writing & Trojans, or media giants infecting hundreds of thousands of Windows PC's with root kits; it's phishing attacks and identity theft, distributed denial of service (DDoS) attacks and of course the perennial spam problem.

Wow. Stop to consider all that and you might think that they are out to get you, and you would be right! Believe it or not the average home PC is a valuable target for all sorts of criminal activity. Identity theft is an escalating problem and even if you have no information of value on your PC the very fact that it's connected to the internet by increasingly faster broadband connections makes it a valuable resource to launch DDoS attacks from. DDoS attacks being the favourite mechanism with which to enforce the lucrative blackmail campaigns against on-line businesses in recent years.

Even if your silly enough to disregard the threat of identity fraud, you still have a social responsibility to secure your PC. Much like you secure your home or car with locks to deter criminal activity you should also take personal responsibility for securing your PC or other devices connected to the internet. The very first responsible thing you can do is choose not to use software which is insecure by design but you know that already. That's why you dropped the hacker honey pot combination of Windows/Internet Explorer/Outlook Express and that's why you're reading about making your Linux PC even more secure.

What is AppArmor?

In a nutshell, AppArmor is a security framework for applications. AppArmor prevents applications from performing undesirable actions and enforces good application behaviour. It can protect against flaws in applications that lead to exploits, even 0-day exploits. A more detailed description can be found on the AppArmor page

Will it stop me from getting hacked or r00ted?

This is a difficult question to answer, it's perhaps impossible to guarantee that one single security tool can prevent malicious attack of any kind. Computer security is often described as a chain, with the whole security of the system only as strong as the links in the chain, one weak link and the chain breaks. Managing security is about managing and mitigating risk. Using AppArmor mitigates against certain types of attack and in some cases completely prevents certain attacks. With this chain analogy in mind then AppArmor significantly increases increases your workstation security; however I would urge anyone considering using AppArmor or extending their use of AppArmor within SUSE Linux to not solely rely on it but to use it in conjunction with other security tools and threat mitigation.

AppArmor & SUSE Linux

AppArmor is included in both SUSE Linux 10.0 &10.1 however as usual SUSE Diary will focus on 10.1. AppArmor is enabled by default in 10.1 and is already protecting certain applications, utilities & libraries.

## Update ## Thanks to Seth Arnold for this suggestion.
The man documentation pages for AppArmor are very clear and helpful, you can list the available man pages for all the AppArmor utilities with:
man -k aa-
Also, konqueror in KDE has a nice plug-in for viewing man pages, for example enter man:aa- in the konqueror address bar and it will list the available AppArmor man pages for viewing in a nice formatted output. Tab completion also works for this plug-in.

If for any reason you did not install AppArmor with your installation or upgrade then you can install the following packages from the SUSE Linux 10.1 installation media or one of the on-line installation repositories.


If you are unsure of how to add additional installation repositories please see the SUSE Diary article showing how to install software using the new package management tools in SUSE 10.1

As you can see, AppArmor for SUSE Linux includes some pre-configured profiles, utilities a YaST2 module and documentation. AppArmor source is also available if you want to try building it for another distro

How AppArmor works

AppArmor works at the kernel level by restricting applications to certain access and operations as defined by an application policy. In SUSE Linux this is provided by a kernel module 'apparmor'. The policies themselves are text files outlining permissions and capabilities using very familiar UNIX like semantics.

The permissions are the familiar read, write and execute, as well as link. The capabilities are POSIX.1e compatible as defined in the capabilities man page. An AppArmor confined process can restrict privileged operations such as reboot, create_module, mount etc.

Securing an application - Firefox

As as said before, some applications are protected by default in SUSE Linux 10.1, these include postfix and syslogd and certain utilities such as ldd, ping, netstat. There are extra profiles included with the AppArmor package but please have a look at the REAME before using them.


For demonstration purposes though I'm going to assume that there is no preconfigured profile for the application you want to secure, in this case Firefox.

Securing an application with AppArmor involves the following steps and is a fairly simple process, the AppArmor utilities automate most of the profiling for you.

  1. Create a profile for the application you wish to secure
  2. Load the profile in learning(complain) mode
  3. Modify the profile based upon learning mode results
  4. Load the finished profile in enforcement mode

Creating a profile

To create a profile for an application you can either use the genprof command line utility or you can use the GUI module in yast. The functionality of the two methods is almost identical so its really a matter of personal preference. Lets create a profile for Firefox now.

using genprof on the command line:

excession:/home/cenuij # genprof firefox
Writing updated profile for /usr/lib/firefox/
Setting /usr/lib/firefox/ to complain mode.

Please start the application to be profiled in
another window and exercise its functionality now.

Once completed, select the "Scan" button below in
order to scan the system logs for AppArmor events.

For each AppArmor event, you will be given the
opportunity to choose whether the access should be
allowed or denied.

Profiling: /usr/lib/firefox/

[(S)can system log for SubDomain events] / (F)inish

Here 'genprof' does a few things. First it resolves the application path and then checks to see if there is already an existing profile. If no profile exists it uses the AppArmor utility 'autodep' to create a basic profile containing the path to the application and uses 'ldd' to include any library dependencies. It saves the basic profile in /etc/apparmor.d using the naming convention of replacing any slashes in the application path with full-stops ( periods ). So the Firefox profile is saved as /etc/apparmor.d/ Lastly, 'genprof' loads this profile in learning(complain) mode and asks you to start using the application so that the necessary access and resources the application needs can be learnt.

Lets look at the same thing using the 'Add Profile Wizard' in the AppArmor YaST Module

Diagram 1: AppArmor YaST module

Diagram 2: Enter application name or browse for it

Diagram 3: During application profiling

When your using your application while the basic profile is loaded in learning mode, access to files and directories, calls to other applications and privileged operations are logged in the system log with a marker that allows AppArmor to learn what the application does.

When your sure that you have used the capabilities of the application now you can continue and modify the profile to allow or disallow the things that AppArmor has learnt about your application.

Close the application and either go back to the console window or press the button in YaST. Lets look at what's next in genprof command line first. Press 'S' to continue.

[(S)can system log for SubDomain events] / (F)inish

Now genprof will ask you a series of questions based upon what it has learnt about your application. The first set of questions relate to other binaries or applications that your program may have accessed.

Profile: /usr/lib/firefox/
Program: firefox
Execute: /bin/basename
Severity: unknown

[(I)nherit] / (P)rofile / (U)nconfined / (D)eny / Abo(r)t / (F)inish

Here Firefox has accessed /bin/basename and you have a choice of three execute modes or deny access.

Inherit: With this mode the program accessed runs with the same AppArmor profile as Firefox, you would normally choose this for helper programs. An example of a helper program would be Firefox requesting to use Adobe Acrobat Reader.

Profile: Profile access requires that the program being accessed runs has its own AppArmor controlled state with its own profile. An example of this would be if your application needed access to a system service such as DNS.

Unconfined: Allows the program being called to run in an unconfined state. This choice should be avoided unless absolutely necessary.

Lets look at the same choices in YaST ( Diag. 4 )

Diagram 4: Profile wizard - access settings for external applications or services

After you have specified permissions for programs your application may access you are then asked similar questions about which files, directories and file paths that your application should have access to.

In genprof on the command line:

Profile: /usr/lib/firefox/firefox-bin
Path: /home/cenuij/.Xauthority
Mode: r
Severity: 4

1 - /home/cenuij/.Xauthority
[2 - /home/*/.Xauthority]

[(A)llow] / (D)eny / (G)lob / Glob w/(E)xt / (N)ew / Abo(r)t / (F)inish

Here you are provided with what type of access the application requires and you must allow or deny it.

Allow: Allows access

Deny: Denies access

Glob: Modify the original path using wildcards e.g. /home/cenuij/*

Glob w/ext: Modify the original path using wildcards but keep any filename extension e.g. /home/cenuij/*.ext

The same thing in YaST: ( Diagram 5 )

Diagram 5: Profile wizard – access settings for application files and paths

During the course of answering these questions you may be able to select an #include to allow access to. For example you may have the choice of /dev/tty or #include . #include statements allow access to applications and services which already have AppArmor confined profiles.

When all the questions have been answered simply press (F) if your using genprof or press the finish button in the YaST module. Your application profile will now be loaded in secure 'enforcement' mode securing any further use of the program according to your settings.

Generally speaking, the more complex a program then the more complex the policy will be. Also, you should be aware that large or complex programs may require a bit of fine tuning after the initial profile generation. Commonly this is because you want to use some functionality in the program that was not initially used when the applications profile was in learning(complain) mode. Here's a basic troubleshooting scenario using Firefox as an example.

Basic AppArmor troubleshooting

Scenario: You have changed the default location where files will be saved to in Firefox. Files that you download are not saved in that location and cannot be found. Firefox is protected by AppArmor with its own profile.

In this scenario the most likely explanation for being unable to download the files to the new location is that either you did not use the download functionality of Firefox when you were setting up the initial profile; or the profile only allows Firefox access to save files to the original download location.

Solution: To allow Firefox to save downloads to the new location you must update your AppArmor profile with the path of the new default download location.

There are two ways you can modify your Firefox AppArmor profile.
  1. Manually edit the profile to include the new path location.
  2. Load the profile into learning(complain) mode and then use Firefox to download a file to the new location. Use the AppArmor utilities to scan for changes in the application behaviour ( saving files to a new location ) and update the profile using suggested settings.

Method one may be time consuming depending on the complexity of the changes and may also be more prone to bugs and errors. Also consider the security implications of making incorrect manual adjustments to the application profile. However some people just like getting their hands dirty in configuration files and in which case the Novell AppArmor documentation is where you should head to, here's the section on profile syntax and structure.

Method two is pretty easy to do, at the console: either run 'genprof firefox', use your application making sure to utilise the functionality you need, scan the changes when your finished. Alternatively load the profile into learning mode with 'complain firefox', use the program and then run 'logprof' to scan and make the changes.

If you wish to use YaST simply make the changes manually using the 'Edit Profile' option or run the 'Add Profile Wizard' again – see Diagram 1. Running the wizard on an existing profile loads it into learning (complain) mode so you can use the application and learn new functionality.

Additional Help

Additional help for SUSE Linux 10.1 can be found on the mailing lists or alternatively you can drop by the IRC chat channel #suse on freenode IRC network. If you are using KDE in SUSE Linux 10.1 then the IRC chat client Konversation is already configured to connect to the #suse channel on freenode IRC network.

digg this!

Saturday, May 13, 2006

UPDATE:- SUSE 10.1 Package Management

After my post showing how some of the new package management in SUSE 10.1 works, an issue has come to light (props to tech9iner and Ancient1). I guess like all things new in software these days there was bound to be some glitches with the first release.

I posted that you can add online repositories using the command line tool 'rug', and I stated that rug and ZMD are meant to synchronise with yast so your services are available everywhere. Well it seems theres a bug with adding a repo as a YUM source. If you add a service in rug with the option --type=YUM then it may not synchronise. This means you would see updates in the tray applet and you could install from the service using rug command such as 'rug install' but if you opened yast control centre the service would not be listed in the 'Installation Source' module and a search for packages in the yast 'Software Management' module would not find your package.

The solution to this is to add the repository as a ZYPP service in rug. To add the source as a ZYPP service ( packman for example ) use the following paramater for rug.

rug sa --type=ZYPP packman

Depending on the repo your trying to add you may have to change the URL of the service, some repositories keep the YUM metadata in a different location from the ZYPP data for example. Lets take a look at the URL for a guru YUM repo.
Note the YUM metadata is in the RPMS folder, this is technically the correct location to store it for a YUM service. Now the URL to add it as a ZYPP service
The URL for the YUM and ZYPP metadata may be the same for some repositories or it may be different. Some may only have one type of metadata... Your mileage may vary, contact the repository maintainer for information if your stuck.

Thursday, May 11, 2006

A Fresh Start and A Fresh Approach

A Fresh Start

I have wanted to start a SUSE diary for some time. Years ago when I had previously been caretaker for a number of FreeBSD boxen, from time to time I would find some great hands-on examples of administration tasks on the FreeBSD Diary. This struck me as an excellent way to give back something to the community rather than the traditional ( but boring ) foo-boring-task-HOWTO.txt

With the release of SUSE Linux 10.1 there are a number of changes and new additions, also this is the very first time that SUSE Linux has been released being 100% under the openSUSE banner. I had considered upgradging my SUSE 10.0 installation having been quite satisfied testing the release candidates that the upgrade process would be quite smooth. However I felt it would be better for the purposes of a SUSE diary if I simply started afresh. This will hopefully give me plenty of material to post about.

So here we are, I have a shiny fresh installation of SUSE Linux 10.1, I chose a basic installation with KDE desktop. I will use GNOME also for the diary but my personal preference is for KDE and so that's where I will start from.

Once you have installed your SUSE linux 10.1 you'll probably want to setup some 'home comforts'. Certainly for me, mp3 playback using my favourite audio player ( amaroK ) is a must and so this will be my very first task. I'll also setup video playback for the video player Kaffeine so I can playback divX, Xvid , WMV and AVI videos.

To enable mp3 playback in amaroK I will need to install the libxine1 multimedia library, xine-lib multimedia library is installed by default for amaroK but for various reasons that I wont go into it doesnt have mp3 support 'out of the box'. Basic mpeg playback is supported by default in Kaffeine but many videos from my friends and family are encoded using common open source codecs such as xvid or the non oss Windows wmv format. To install all the libraries I need for audio and video playback I'll need to setup access to some 3rd party software repositories. This will give me an excellent opertunity to demonstrate the new default package management utilities in SUSE 10.1

A Fresh Approach - SUSE 10.1 package management

In SUSE 9.x and 10.0 the default package management software was the software management module and yast online update ( YOU ) in YaST2 and the susewatcher system tray applet. The susewatcher applet would faithfully report any security or system updates and would let you launch YOU to download and apply the updates. For third party software you could add online repositories to the installation sources module and ultimately you could manage all your software from the software management module, again in YaST2.

SUSE 10.1 brings some new software for package management to the table. Gone is susewatcher and YOU is no longer the default method of updating SUSE with system and security updates. Libzypp is the new backend software with the Zenworks Management Daemon ( ZMD ) providing an interface for the new notification applet called zen-updater and the default command line utility called rug. Libzypp is a clever mix of red carpet and yast technologies and so has been integrated into yast package management also. This means any installation sources you add to rug/zen-updater will show up in yast and vice versa. Let's get started...

First off I need to setup my package management to a state I'm happy with. I want to be notified of any system or security updates so I'll make sure online updates is configured first. Open YAST Control Centre, choose Online Update Configuration and follow the simple instructions. I prefer to enable this with my hardware profile, if you have purchased a copy of SUSE Linux select the option to include your registration code. This will give you access to official support. The impatient among you can use the console to setup online updates, as root enter the command 'suse_register':

cenuij@excession:~> su
excession:/home/cenuij # suse_register

configure online updates with yast

In the system tray you can see the new notification applet running.

Right-click and choose configure. Now you will see three tabs, in the first 'Services' tab is the list of services ( installation sources ) you have registered. If you have a fresh installation like me you will at least have the installation media you used listed as a service. If you have configured Online Updates it will list this service as well, you will be subscribed to these catalogs.

zen-updater services & catalogs

Now you will be automatically notified of any security or system updates, if there are any available the zen-updater applet will also allow you to install them.

Now that I have online updates configured I want to add a third party software repository and install libxine1 for mp3 playback in amaroK. The packman repsoitory has libxine1 so let's add this as a service. Here is a list of packman mirrors so you can pick one close to you. You will need to browse the mirror you want for the full URL to the repository. For example on the skynet mirror I like, the URL to the repo is

## Update ## At Tony's suggestion here's a link to an update on using the new package management. I would urge you all to read through this as well it will provide some time saving and head scratching when it comes to the point of adding an online repository. Thanks for the suggestion Tony.

Right-click on the zen-updater applet in your system tray and select 'configure'. Click on the 'Add Service' button, enter the URI in the popup, you can let the applet auto detect the service type but I will choose YUM. Give the service name 'packman', the service name acts as an identifier and also the catalog name.

After zen-updater is finished adding the service, click on configure and go to the 'Catalogs' tab. Make sure you are subscribed to the packman catalog by checking the box if neccessary.

You can also use the rug command line utility to add services. As root:
rug sa --type=YUM packman
rug sub packman
You can use rug to install, remove software and to schedule package management tasks as well. There is much more to it so I reccomend checking out the rug manual.

After you subscribe to the packman service you may notice the zen-updater icon in your system tray has changed to indicate there are updates available for some of the software you have on your system. Click on the icon to see the list of available updates. Security and system updates are also listed in YOU.

Now you can install any software from the packman repository. You can use yast software management module to install or remove software from your configured repositories or you can use the new installation tool that comes with zen-updater. To use the new tool; in the GNOME or KDE program menu go to System > Configuration > Install Software.

Do this now to install libxine1 for mp3 playback in amaroK.

You can install the packages from the command line using rug
rug in libxine1
Any package dependancies will now be resolved and you may get prompted to install additional software that's needed. You may also be promted to remove conflicting software. In this case it is neccessary to remove xine-lib and also add additional packages.

Click apply. libxine1 software will now be downloaded and installed on your system, and you will now be able to enjoy mp3 playback in amaroK!

For improved video playback support repeat the installation procedure for the packages xvid, divx and mad. These packages are all available from the packman repository.

Additional Software Repositories

There are additional software repositories you may be interested in for example Guru repository (Yaloki) builds an extensive number of packages for SUSE, including updates to software that might not be available from the official SUSE distribution, for example SUSE 10.1 ships with amaroK 1.3, yaloki has amaroK 1.4 with improved iPod support.

Here is a list of some usefull repositories and the console command to add them as a service

Packman source
rug sa --type=YUM packman
Guru (Yaloki) Source
rug sa --type=YUM guru
mozilla ( firefox, thunderbiord, seamonkey )
rug sa --type=YUM mozilla
Next on SUSE Diary

SUSE Linux 10.1 is the first Linux disrto to ship with XGL. I'll show you how to setup XGL for that *drool* must have eye candy in both GNOME and KDE.

Additional Help

Additional help for SUSE 10.1 can be found on the mailing lists or alternatively you can drop by the IRC chat channel #suse on freenode IRC network. If you are using KDE in SUSE 10.1 then the IRC chat client Konversation is already configured to connect to the #suse channel on freenode IRC network.

digg this!