Stack smashing protector accepted in Arch Linux!

If you visit my blog you may recall I blogged about feature request for enabling stack-smashing protection in Arch Linux. I had created feature request in Arch Linux bug tracker in March 2010. As you can see this initiated some discussions and finally, after almost 1,5 year they decided to go for it! The default compilation flags have been changed to use stack protector and main toolchain packages were recompiled; other packages will follow with new releases. For now the change is in [testing] repo and should become available in [core] in a few weeks.

So, rejoice Arch users! Unfortunately me personally will not benefit from it since I stopped using Arch some time ago - GNOME 3.0 release (which ruined my desktop experience) and power-off issues caused by updates made me look for a more reliable system (which is Debian Squeeze at the moment). I must admit however that I miss Arch a lot, and the acceptance of stack protector reminds me of it...

BTW, Debian still doesn't take advantage of GCC's stack protector, which is a pitty. Fortunately, Debian security team is aware of this and they plan to enable hardening features in Debian Wheezy.

GNOME 3.0 = big letdown

The GNOME project has just released GNOME 3 - a major overhaul of this popular desktop environment - which promises a new, beautiful and improved interface and a shift in the way users access their desktop. I've been using GNOME 2.x for a few years already and had really high hopes about the upcoming release. Unfortunately, all I got is a big letdown.

The key features I loved about GNOME 2 were its simplicity, configurability, extensibility and stability. This is no longer the case with new GNOME. GNOME developers did what KDE developers did a few years ago, by replacing KDE 3.5  with KDE 4.0: they have rewritten their desktop and dropped tons of features to provide "new desktop experience". I don't mind GNOME Shell - in fact I find some of its aspects quite appealing - I just miss the freedom and flexibility of GNOME 2. In GNOME 3 configurable panels are gone, existing panel applets are gone (well, most of them - all the bonobo-based), apperance settings are gone, gdm settings are not configurable (GDM setup tool had been removed a long time ago, around gnome 2.28 and it is still not available).  Not to mention that GNOME 3.0 in its current shape is not really stable and I found some irritating bugs in Gnome Shell after using it just for around one hour.

Some of the missing features will probably be provided by 3rd party tools that I'm sure will fill the vacuum sooner or later, but I'm afraid that reaching the functionality and stability offered by GNOME 2 may need a few development cycles. This makes me a little bit concerned about the state of Linux desktop in the next 1-2 years: with immature GNOME 3 and Ubuntu/Unity abandoning GNOME, the only viable option is to stick with a distribution that still supports GNOME 2, or move to XFCE. The current state of affairs may be a big chance for the latter, by the way.u

After testing GNOME 3 & XFCE 4.8 in Arch Linux for a few days, I've sadly decided to abandon Arch Linux... The disadvantage of running a rolling distro is that updates such as GNOME 3 are just rolled out and you either accept it or refuse them (and stop getting security updates at the same time)... And for all these reasons I decided to move to  Debian 6.0 (Squeeze) and stick with it for a while... Let's see how GNOME 3 and Unity develop. Maybe by the time of next Debian stable GNOME 3 becomes really usable?

Kernel 2.6.36 bug = OOPS

Apparently the stable Linux Kernel 2.6.36 has a severe regression / bug that results in frequent (but random) crashes at the early stages of boot process. I've been experiencing this issue for around one week but considered it a problem with my setup or hardware. It turns out the problem is widespread among Arch Linux users (and others running bleeding edge distors, such as Slackware-current) and is triggered by latest udev-165-1 update. It has been discussed on the Arch Linux forums and reported in Arch Linux bugtracker and Kernel bugzilla.
For now the easiest solution is to downgrade udev to version 164-3. There are two ways to do this: using the old package from /var/cache/pacman/pkg (if you haven't cleaned your pacman cache) or downloading it from the great Arch Rollback Machine (it already saved me once!). Note: Make sure you recreate your initrd image with 'mkinitcpio -p kernel26' after reverting to older udev!

Arch Linux defaults to Python 3 now

A major update has recently been pushed with Arch Linux updates: Python 3 is now the default one, installed as /usr/bin/python. The old python interpreter is installed as /usr/bin/python2.  This change resulted in a bunch of updates to other python-dependant packages.  Python 3 breaks compatibility with Python 2.x series, so this is a bold move but hey, Arch Linux rocks :-), doesn't it? Using Python 3 as the default in the stable branch puts Arch Linux at the forefront of Linux distros. The list of new features and changes in Python 3.x series are listed here.

Why do I love Arch Linux

This is what I got by issuing 'pacman -Syu' (update of all packages to the latest version from the repos) this morning... For all the oblivious: this is mostly GNOME 2.32 stuff released a few days ago :). Sweeet.

Arch Linux & AppAarmor

I've just recently started to work on bringing the boon of AppArmor to Arch Linux world. PKGBUILDs for AppArmor-patched kernel and userland tools will soon be published via AUR, just some things need to be polished and finished.  Preparing kernel package went smooth.  The major effort was to prepare PKGBUILD for AppArmor tools: they should be punished for what they did to its Makefiles. Hardcoded paths to some crucial utiilities (like pod2man), hardcoded dependency/use of rpm, default target that generates not only the binary, but also pdf documentation (and for that you need latex)... Just nightmare... The PKGBUILDs are mostly ready, I just need to put some more effort and create an /etc/rc.d startup script for AppArmor's aa-eventd.  Stay tuned for AppArmor packages for Arch Linux!

Feature request: enable stack smashing protector for Arch Linux packages

I've just created a feature request in Arch Linux Bugtracker to enable stack-smashing protector for Arch Linux packages. Stack smashing protector (SSP for short, aka ProPolice) is a GCC extension for protecting applications from stack-smashing attacks. It is available in stock GCC via -fstack-protector and -fstack-protector-all compile flags.

If you care about Arch Linux security, plase speak up and vote for this feature request!

iwl4965 driver bug & a workaround

I've been experiencing random wifi disconnections for a couple of months from now, but assumed these were problems with my AP or with Network Manager. Until now. I've just recently spotted messages indicating firmware/driver problems in dmesg output (I'm running kernel 2.6.30):

Oct  1 16:25:11 pc kernel: wlan0: associated
Oct  1 16:27:21 pc kernel: iwlagn 0000:03:00.0: Microcode SW error detected.  Restarting 0x82000000.
Oct  1 16:27:21 pc kernel: Registered led device: iwl-phy0::radio
Oct  1 16:27:21 pc kernel: Registered led device: iwl-phy0::assoc
Oct  1 16:27:21 pc kernel: Registered led device: iwl-phy0::RX
Oct  1 16:27:21 pc kernel: Registered led device: iwl-phy0::TX
Oct  1 16:28:54 pc kernel: wlan0: disassociating by local choice (reason=3)


Google reveals several bug reports for this error for many popular Linux distributions: Ubuntu, Fedora, Gentoo, Arch...; it was also reported on Intel's bugzilla. The bug has been known for months but it looks like it's not apparent what's its root cause. The problem occurs under high traffic volume or after long inactivity. The connection doesn't work anymore, but it is not reported as such by NetworkManager or iwconfig. To get it working again,you have to reconnect with NetworkManager or reload iwlagn module.

 It seems there are two workarounds, I've tested both of them and both worked for me:

• set "swcrypto=1" option for iwlagn module using modprobe.conf
• use ndiswrapper driver, that is, the wrapper for MS Windows driver.

Of course 1st option is recommended if it works for you. Ndiswrapper works well, except for its ntos process may take as much as 80% CPU under high load (e.g. 200K/s transfer) and around 9% with no traffic (running on 2GHz Core2Duo)... It's not noticable on Core2Duo though.

Judging from the changelong for RC of kernel-2.6.32, there is a buch of fixes related to Intel wireless drivers (and iwl4965 in particular), let's hope the problem will be gone when 2.6.32 is finally released.

Arch Linux with TOMOYO Linux MAC

I had mentioned in my mini review of Arch Linux about no official support for Mandatory Access Control solution such as SELinux or AppArmor and also outlined the importance of MAC when writing
about AppArmor a few months ago.  I'm very happy with my Arch Linux installation, but one thing that bothered me was no ability to protect crucial applications and system against unknown vulnerabilites. So I decided to put some effort and install a MAC implementation on my system. This blog entry is about how it went.

The problem with software bugs is you cannot avoid them. Developers make bugs and even if you keep your system updated, you are still endangered by zero-day bugs and hidden, undisclosed bugs.  If you think you're on the sunny side because your're not a server administrator, just a workstation user, then you're mistaken. You may get hacked by just visiting a malicious web site that exploits a yet-unknown vulnerability in your web browser or by opening a crafted PDF file that exploits a bug in your PDF viewer software.

With Mandatory Access Control you can "enclose" selected applications in secured domains with precisely defined resources and privileges for that application. If bug in secured application is exploited, an attacker cannot perform any operations not defined in that application's policy rules.

OK, now onto choosing the right MAC implementation. This depends on your needs, determination, time, knowledge and willingness to learn. When looking for a solution for Arch Linux I initially considered two implementations: AppArmor and SELinux.
• AppArmor is something I'd preferr over SELinux for my needs, but the status of AppArmor development is not clear to me. The latest kernel patch available on the official web site is for kernel 2.6.26, so it's a bit outdated.  On the other hand AppArmor will be shipped with new Ubuntu 9.10 (kernel 2.6.31), so obviously there are people who maintain it, but I could not find any new patches.... Strange.
• SELinux would be an overkill for a workstation. I'm just not willing to tackle with file labelling and complex policies just to protect a few applications. Besides that, it's seems to be hard to protect Mozilla Firefox with SELinux labelling. The nice thing about installing SELinux is it can be easily installed using Community packages.

I kept looking and found two other solutions that recently emerged in Linux world:
• SMACK - Simplified Mandatory Access Control - available in stock kernels starting from kernel 2.6.24.
• TOMOYO Linux - available with limited functionality in stock kernels starting from kernel 2.6.30 (but not enabled in Arch Linux kernel). Also available as a separate kernel patch with full functionality.

SMACK is a "SELinux for dummies"; it uses lables and extended attributes, but is much more easy to use than SELinux. Tomoyo is similiar in concept to AppArmor - it uses path names as security labels. It can be easily installed on Arch using PKGBUILD from AUR. Keeping all the above in mind (complexity of administration, availability) I decided to give Tomoyo a try.

 
Installation is easy. Just build and install kernel26 and ccs-tools from AUR (note: this is TOMOYO 1.6.8 with full MAC functionality) , update grub config file, reboot the system, initialize policy files and it's ready to use (basic setup is well described in TOMOYO's HOWTO). The majority of work is with creating application policies. Fortunately, TOMOYO has a really powerful learning mode. Here is how to use it:

1. Start application just once so that TOMOYO knows about it, then quit it.
2. Run ccs-editpolicy and find that application on the domains list (see screenshot) and highlight it.
3. Press 'S' and then '1' to enable learning mode for it.
4. Excercise your application a bit - perform as many actions as possible. Policy rules for this application will be generated automatically and kept in kernel memory.
5. When you're done, press 'S' again and then '3' to enable enforcing mode for your application. Alternatively, you can use '2' for permissive mode (all actions are permitted but potential denials will be written to log file - useful for testing purposes).
6. Save the policy with 'ccs-savepolicy'. This stores current policy from kernel memory to /etc/ccs/* files.
7. Adjust the /etc/ccs/domain_policy.conf and /etc/ccs/exception_policy.conf with a text editor. You'll most likely need to change any specific file paths occuring in the policy (like /home/john/.mozilla/firefox/6y78dadq.default/Cache/yiaud) with file patterns (e.g. /home/\*/.mozilla/firefox/\*/Cache/\*).
8. Reload the policy with 'ccs-loadpolicy de'; this loads current policy from files to kernel memory.
   

You can repeat above steps as many times as needed.

There is hovewer one catch to be aware of.  Policy rules are defined per execution domain. In TOMOYO domains are defined by process invocation history (PIH), that is, a concatenated list of executables that lead to the execution of specific application. This means that "/sbin/init /usr/bin/gdm /usr/sbin/gdm-binary /etc/gdm/Xsession /usr/bin/ssh-agent /usr/bin/gnome-session /usr/bin/gnome-panel /usr/bin/transmission /usr/lib/firefox-3.5/firefox" domain is different from " /sbin/init /usr/bin/gdm /usr/sbin/gdm-binary /etc/gdm/Xsession /usr/bin/ssh-agent /usr/bin/gnome-session /usr/bin/gnome-panel /usr/lib/firefox-3.5/firefox", even though in both cases Mozilla Firefox was executed. In the first case Firefox was started by Transmission, in the second case it was started by Firefox shortcut on the panel. The number of domains Firefox could be started in is potentially infinite, because you can start it via ALT+F2 in GNOME, xterm, gnome-terminal etc. You may think you'll end up with duplicating policy rules for all possible domains Firefox can be started in (not a good idea...), but fortunately Tomoyo has solution for this:  you've to add 'initialize_domain /usr/lib/firefox-3.5/firefox' definition to /etc/ccs/exception_policy.conf and define policy rules for " /usr/lib/firefox-3.5/firefox" domain.  It's so simple.  From now on, whichever way you choose to start Firefox, Tomoyo will use just one domain definition and same rule set. Don't underestimate PIH though, as PIH is a a powerful tool to define various polices for same application, depending on its invocation history (well... that was obvious, hmm...). You can, for example, define different rules for /bin/cat executable, depending on whether it was used in /usr/bin/foo.sh script or /usr/bin/bar.sh script.

Ok, this is enough. It's time to summarize best features of TOMOYO Linux:
• Easy to set up. No existing userland tools need to be modified.
• Easy policy language.
• Great learning mode.
• Ability to modify policies on-the-fly.
• No impact on performance (according to Tomoyo Linux authors, performace hit is within measurements error).

If you need a MAC solution which is easy to setup and use and you understand the differences between path-based (TOMOYO, AppArmor) and label-based (SELinux, SMACK) solutions, then you should definately give Tomoyo Linux a try. I think it's superiror to AppArmor and now as it made it's way into Linux Kernel, it seems it has a bright future. Congratulations, TOMOYO team!

UPDATE: I've been contacted by Tetsuo Handa (one of the Tomoyo developers) with a rectification about performance: there is some impact on performance, and performance impact of TOMOYO is larger than SELinux (as it entails string comparison with pattern patching), but users
 won't notice unless CPU is too slow. Some people tried to measure the performance hit, but they got bizzare results.

Arch Linux

I admit that, I'm a distro junkie and Linux addict and just can't resist trying different distros... I've been using Linux on regular basis for over 12 years and tried several distros, but haven't found the perfect one so far. This time I was tempted to try out Arch Linux - a versatile distro designed with accordance to KISS principle and targeted at advanced users. After around one week of playing with it I can say it's close to meet all my requirements for a perfect distro. Ok, it's not 100% perfect, but really close. Main advantages of Arch Linux in my humble opinion are:

• It's blazing fast. I mean it. It boots really quickly and GNOME + Firefox feels much snappier then in other distros.
• It's customizable. Ok, you can say it about most distros, but with Arch you're not forced to choose any path. You start with a bare minimum (just core system packages) and install whatever you want on top of it. Do you want pulseaudio? Here you are. Do you hate pulseaudio? That's fine too.
  
• It's brain dead simple to customize & recompile packages with custom options and features, thanks to tools such as pbget, customizepkg and makepkg. It's equally easy to create your own packages from scratch, as all you need is a simple PKGBUILD file.
  
• It's a rolling-release system, meaning most packages are up-to-date all the time and you may be on the bleeding edge to your liking.
• It'sa binary distro after all, optimized for i686 (x86_64 is also available). No need to waste time & CPU time to compile all the stuff.
• Basic aspects of system configuration (deamons, modules, network etc.) are easily configurable via a single /etc/rc.conf file. Daemons may be started in background (i.e. in parallel) making the system boot faster.
  
• Pacman (Arch Linux package manager) is damn fast.
• It has a good and helpful Wiki pages as well as supportive community.
  

Ok, I mentioned Arch was not perfect, so now onto downsides:

• Setting it up takes time. It took me around 5 hours to install and tune the system to my needs. This included installation of Xorg, GNOME, multimedia stuff as well as some tools and libraries I use for developing my projects (Qt Designer, boost, cmake, git, emacs etc.). The main issue I had was with GDM - it turned out I had to use a specific GDM option (GdmXserverTimeout=60) to get it working correctly. On the orher hand, you do it once and forget about it.
  
• Things may occasionally break if you upgrade your system blindly without paying attention to what's going to be updated.
• The official repositiories lack some less known or less popular packages.
  
• AUR repository (the repository of user-provided PKGBUILD scripts for additional packages that are not included in offical repos) is not something you can count on. It contains user content of varying quality. Some PKGBUILDs may be outdated or broken. On the other hand however I had to use AUR for 5 packages only: Opera web browser, grandr-applet, pbget, ttf-droid fonts and xephem.
• There is no official support for security enhancements like AppArmor or SELinux. SELinux is available in the community repository only. I consider a MAC enhancements a must in today's systems; at least selected applications should be executed in confined environments.
  

I'd definately recommended Arch to everyone with some prior Linux experience. It should be particularly valued by advanced users, developers and open-source enthusiasts who like to use the newest and hottest software.