Gentoo Logo
Gentoo Logo Side
Gentoo Spaceship

Contributors:
. Aaron W. Swenson
. Agostino Sarubbo
. Alec Warner
. Alex Alexander
. Alex Legler
. Alexey Shvetsov
. Alexis Ballier
. Alistair Bush
. Amadeusz Żołnowski
. Andreas K. Hüttel
. Andreas Proschofsky
. Andrew Gaffney
. Anthony Basile
. Arun Raghavan
. Bernard Cafarelli
. Bjarke Istrup Pedersen
. Brent Baude
. Brian Harring
. Christian Faulhammer
. Christian Ruppert
. Christopher Harvey
. Chí-Thanh Christopher Nguyễn
. Constanze Hausner
. Dane Smith
. Daniel Gryniewicz
. David Abbott
. Denis Dupeyron
. Detlev Casanova
. Diego E. Pettenò
. Domen Kožar
. Donnie Berkholz
. Doug Goldstein
. Eray Aslan
. Fabio Erculiani
. Gentoo Haskell Herd
. Gentoo News
. Gilles Dartiguelongue
. Greg KH
. Hanno Böck
. Hans de Graaff
. Ian Whyman
. Ioannis Aslanidis
. Jan Kundrát
. Jeffrey Gardner
. Jeremy Olexa
. Joachim Bartosik
. Joe Peterson
. Johannes Huber
. Jonathan Callen
. Jorge Manuel B. S. Vicetto
. Joseph Jezak
. Josh Saddler
. José Alberto Suárez López
. Kenneth Prugh
. Krzysiek Pawlik
. Lance Albertson
. Liam McLoughlin
. LinuxCrazy Podcasts
. Luca Barbato
. Luis Francisco Araujo
. Marcus Hanwell
. Mark Kowarsky
. Mark Loeser
. Markos Chandras
. Markus Ullmann
. Mart Raudsepp
. Matt Turner
. Matthew Marlowe
. Matthew Thode
. Matthias Geerdsen
. Matti Bickel
. Michal Hrusecky
. Michal Januszewski
. Michał Górny
. Mike Doty
. Mike Gilbert
. Mike Pagano
. Mounir Lamouri
. Mu Qiao
. Nathan Zachary
. Ned Ludd
. Nirbheek Chauhan
. Ole Markus With
. Olivier Crête
. Pacho Ramos
. Patrick Kursawe
. Patrick Lauer
. Patrick McLean
. Paul de Vrieze
. Paweł Hajdan, Jr.
. Petteri Räty
. Piotr Jaroszyński
. Rafael Goncalves Martins
. Raúl Porcel
. Remi Cardona
. Richard Freeman
. Robert Buchholz
. Robin Johnson
. Romain Perier
. Ryan Hill
. Sean Amoss
. Sebastian Pipping
. Serkan Kaba
. Steev Klimaszewski
. Steve Dibb
. Stratos Psomadakis
. Stuart Longland
. Sune Kloppenborg Jeppesen
. Sven Vermeulen
. Sven Wegener
. Thilo Bangert
. Thomas Anderson
. Thomas Kahle
. Tim Sammut
. Tiziano Müller
. Tobias Heinlein
. Tobias Klausmann
. Tobias Scherbaum
. Tomáš Chvátal
. Torsten Veller
. Victor Ostorga
. Vikraman Choudhury
. Zack Medico
. Zhang Le

Last updated:
August 05, 2012, 14:29 UTC

Disclaimer:
Views expressed in the content published here do not necessarily represent the views of Gentoo Linux or the Gentoo Foundation.


Bugs? Comments? Suggestions? Contact us!

Powered by:
Planet Venus

Welcome to Planet Gentoo, an aggregation of Gentoo-related weblog articles written by Gentoo developers. For a broader range of topics, you might be interested in Gentoo Universe.

August 05, 2012
Gentoo Website survey 2012 launched (August 05, 2012, 10:03 UTC)

Building a website that fits the needs of users and editors alike is hard. That's why the Gentoo PR team would like to ask you a few questions about our websites, mainly www.gentoo.org, but also about our other sites.

Take the survey now

Thanks for your time and interest in making our website experience better!

Gentoo Screenshot Contest 2012 (August 05, 2012, 10:03 UTC)

After the success of the 2011 Screenshot Contest the Contest Team is doing it again!

Gentoo Users, Developers, and Staffers are encouraged to submit their sweetest screenshots. This year likewhoa went all out and put together a custom cms for us to use for the contest. Please head over to the 2012 Contest Page for all of the details.

You can visit this forum post for comments and suggestions. OK enough talk, get started tricking out that desktop.

x32 ABI release candidates (August 05, 2012, 10:03 UTC)

We are pleased to announce the initial x32 release candidate. This is a new ABI for amd64 platforms that aims to marry the best of both worlds: smaller pointers from 32bit x86 with more registers and enhanced instructions from 64bit x86_64. All you need to get started is Linux 3.4!

For more information, please check out the Gentoo developer mailing list.

ARM v6+ stages switching to hardfp (August 05, 2012, 10:03 UTC)

From now on, we are defaulting ARMv6 and ARMv7 targets to hardfp. Since the ARM definition for these cores mandates vector floating point units, it would be silly to continue defaulting these to soft float. This also keeps us in sync with the cross-distro standardization that is occurring in the ARM space.

More specifically, ARMv6 targets will default to "vfp" while ARMv7 targets will default to "vfp3-d16". This will cause upgrade pains for existing installs, and that makes us sad, but we're looking at the long term here. Updated stages should be available already.

If you have any questions, please consult the Gentoo embedded mailing list.

Gentoo at LinuxTag 2012 in Berlin (August 05, 2012, 10:03 UTC)

LinuxTag 2012 runs from May 23rd to May 26th in Berlin, Germany. With more than 10,000 visitors last year, it is one of the biggest Linux and open source events in Europe.

You will find the Gentoo booth at Hall 7.2b, Booth 273. Come and visit us! You will meet many of our developers and users, talk with us, plus get some of the Gentoo merchandise you have always wanted.

Today, the most ambitious Free Software event of the Czech Republic officially opens registration! We’ve got an awesome event for you in store with sessions on all major subjects in Free Software and around it. Entry will be free of charge for everyone and we’ll give you 4 events AND a bonus track for that money! One of the events will be our very own Gentoo Miniconf 2012.

We hope to see you all in Prague on October 20-23 2012!

Theo Chatzimichos provided the draft for this announcement.

If you've always wanted to visit the lovely city of Prague, here's a reason to finally do it: On October 20th and 21st the city is going to be hosting numerous open-source related conferences, including the Gentoo Miniconf.

This is a great opportunity to meet each other and hack on Gentoo together.
We're going to have a room just for ourselves to discuss, give presentations and workshops, do some ebuild hacking, and much much more.
Thanks to the other conferences we're co-hosted with, we expect lots of local and international visitors who can enjoy plenty of talks for all levels of Gentoo proficiency.

For more information, please visit the conference website which provides details about all the events that are going to take place.
Information specific to the Gentoo Miniconf can be found on our website.

Call for papers started
If you would like to give a presentation, hold a workshop or lead a BoF session, please hand in your session proposals. The registration deadline for the CfP is August 1st.

We hope to see you all in Prague this October!

Theo Chatzimichos provided the draft for this announcement.

Usually we bring you news in writing. This time we have something special though: Gentoo developer Jeff Horelick talked to Randal Schwartz and Aaron Newcomb of FLOSS Weekly, a podcast about free and open source software.

You can listen to the recording on the podcast's website.

Gentoo at FOSSCOMM 2012 (August 05, 2012, 10:03 UTC)

What? FOSSCOMM 2012

When? 12th, May 2012 - 13th, May 2012

Where? Technological Educational Institute of Serres, Greece

FOSSCOMM 2012 is almost here, and Gentoo will be there!

Check out our Gentoo presentation and workshop on DistCC/CrossDev. We will have a booth with Gentoo promo stuff, flyers, stickers, badges, live CD's, DVD's and much more! Whether you're a developer, user, or simply curious, be sure and stop by. See you there!

Dimitris Papapoulios and Pavlos Ratis contributed the draft for this announcement.

Students, only a few days remain to apply for Gentoo's 7th year in the Google Summer of Code! GSoC pays college students $5000 to work full-time on an open-source project for a summer. Check out our GSoC 2012 homepage if you are interested in this year's GSoC for Gentoo. We particularly encourage applications from students who are new to Gentoo development—many of our students become Gentoo developers after a successful summer.

Interested students can browse Gentoo's project ideas. Student applications will be accepted until 1900 UTC April 6, so start now if you haven't already!

Developers, if you'd like to apply to be a mentor, you can do so on the webapp. Please read the mentoring guide before applying.

August 04, 2012

Seems obviously for many of you, but a lot of people in the past, ask me how to test toolchain components and be sure to don’t break anything.

Ok, as usual we will start to test the singular package with multiple USE combinations. Don’t expect that should work with USE=”vanilla”; for who don’t know:

Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically

If the various tests passes without build failure, now, you should try to recompile your system, to check if the new package could break something, so:
emerge -e system

If there are failures, check if them are related to what you are testing(e.g. don’t post zlib failures when you test binutils). If you don’t know how to understand who causes the failure, just poke a developer on irc.

If you have a powerful machine, or it should be in idle, feel free to rebuild entire world.
Obviously for failures, file a bug and block the stabilization bug or the tracker.

August 03, 2012
Always looking for arch tester(s) (August 03, 2012, 20:23 UTC)

We always looking for new arch testers.

Simple answers to possible questions:
1) What you should do? you should test the packages on a specific architecture on a stable environment.

2)Do you use also ~arch packages? No problem, there is a way to set a stable chroot.

3)You not believe you have the skill to do it? wrong. You will be ‘guided’ to do an excellent work, so is an opportunity to ‘grow’.

What you need is: love for gentoo and time to devote.

This post is not related only for amd64; you can contribute with any architecture you are using.
To join, for amd64, feel free to contact me (via mail) and/or read
1) FAQ
2) Official Page

If you are using a different arch from amd64, contact me as well, I will guide you to the right way.

July 31, 2012
Matthew Thode a.k.a. prometheanfire (homepage, stats, bugs)

Disclaimer

  1. Keep in mind that ZFS on Linux is not fully supported and stuff...
  2. I don't care much for hibernate, normal suspending works.
  3. This is for a laptop/desktop, so I choose multilib.
  4. If you patch the kernel to add in ZFS support directly, you cannot share the binary, the cddl and gpl2 are not compatible in that way.

Initialization

Make sure your installation media supports zfs on linux and installing whatever bootloader is required (uefi needs media that supports it as well). You can use the Gentoo LiveDVD, look for 12.1 or newer for the zfs portion of it, then, if you need to install the bootloader via uefi, you can use one of the latest fedora CDs. This is the method I used on my 2011 MacBook Pro, because Apple hardware is 'special'. You can install your system normally up until the formatting begins.

Formatting

I will be assuming the following.

  1. /boot on /dev/sda1
  2. cryptroot on /dev/sda2
  3. swap inside cryptroot OR not used.

When using GPT for partitioning, create the first partition at 1M, just to make sure you are on a sector boundry

General Setup

#setup encrypted partition
cryptsetup luksFormat -l 512 -c aes-xts-plain64 -h sha512 /dev/sda2
cryptsetup luksOpen /dev/sda2 cryptroot

#setup ZFS
zpool create -f -o ashift=12 -o cachefile= -O normalization=formD -m none -R /mnt/gentoo rpool /dev/mapper/cryptroot
zfs create -o mountpoint=none -o compression=on rpool/ROOT
#rootfs
zfs create -o mountpoint=/ rpool/ROOT/rootfs
zfs create -o mountpoint=/opt rpool/ROOT/rootfs/OPT
zfs create -o mountpoint=/usr rpool/ROOT/rootfs/USR
zfs create -o mountpoint=/var rpool/ROOT/rootfs/VAR
#portage
zfs create -o mountpoint=none rpool/GENTOO
zfs create -o mountpoint=/usr/portage rpool/GENTOO/portage
zfs create -o mountpoint=/usr/portage/distfiles -o compression=off rpool/GENTOO/distfiles
zfs create -o mountpoint=/usr/portage/packages -o compression=off rpool/GENTOO/packages
#homedirs
zfs create -o mountpoint=/home rpool/HOME
zfs create -o mountpoint=/root rpool/HOME/root

cd /mnt/gentoo

#Download the latest stage3 and extract it.
wget ftp://gentoo.osuosl.org/pub/gentoo/releases/amd64/autobuilds/current-stage3-amd64-hardened/stage3-amd64-hardened-*.tar.bz2
tar -xf /mnt/gentoo/stage3-amd64-hardened-*.tar.bz2 -C /mnt/gentoo

#get the latest portage tree
emerge --sync

#copy the zfs cache from the live system to the chroot
mkdir -p /mnt/gentoo/etc/zfs
cp /etc/zfs/zpool.cache /mnt/gentoo/etc/zfs/zpool.cache

Kernel Config

If you are compiling the modules into the kernel staticly, then keep these things in mind.

  • When configuring the kernel, make sure that CONFIG_SPL and CONFIG_ZFS are set to 'Y'.
  • Portage will want to install sys-kernel/spl when emerge sys-fs/zfs is run because of dependencies. Also, sys-kernel/spl is still necessary to make the sys-fs/zfs configure script happy.
  • You do not need to run or install module-rebuild.
  • There have been some updates to the kernel/userspace ioctl since 0.6.0-rc9 was tagged.
    • An issue occurs if newer userland utilities are used with older kernel modules.

Install as normal up until the kernel install.

echo "=sys-kernel/genkernel-3.4.40 ~amd64       #needed for zfs and encryption support" >> /etc/portage/package.accept_keywords
echo "=sys-apps/openrc-0.9.9.3 ~amd64           #needed for zfs support" >> /etc/portage/package.accept_keywords
echo "=sys-kernel/gentoo-sources-3.5.0 ~amd64   #needed for non-module zfs" >> /etc/portage/package.accept_keywords
emerge sys-kernel/genkernel
emerge sys-kernel/gentoo-sources

#patch the kernel
wget http://dev.gentoo.org/~prometheanfire/dist/kernel-patches/linux-3.5.0-gfp-vmalloc.patch -O - | patch -p1 -d /usr/src/linux

#If you want to build the modules into the kernel directly, you will need to patch the kernel directly.  Otherwise, skip the patch commands.
wget http://dev.gentoo.org/~ryao/dist/linux-3.5.0-zfs.patch -O - | patch -p1 -d /usr/src/linux
wget http://dev.gentoo.org/~prometheanfire/dist/kernel-patches/linux-3.5.0-zfs-builtin.patch -O - | patch -p1 -d /usr/src/linux

#finish configuring, building and installing the kernel

#if not building zfs into the kernel, install module-rebuild
emerge module-rebuild

#install SPL (needed for ZFS)
echo "=sys-kernel/spl-0.6.0_rc9-r2 ~amd64       #needed for zfs support" >> /etc/portage/package.accept_keywords
emerge sys-kernel/spl

#install zfs utils
echo "=sys-fs/zfs-0.6.0_rc9-r6 ~amd64           #needed for zfs support" >> /etc/portage/package.accept_keywords
emerge sys-fs/zfs

# Add zfs to the correct runlevels
rc-update add zfs boot
rc-update add zfs-shutdown shutdown

#initrd creation, add '--callback="module-rebuild rebuild"' to the options if not building the modules into the kernel
genkernel --luks --zfs --disklabel initramfs

Finish installing as normal, your kernel line should look like this, and you should also have a the initrd defined.

#kernel line for grub2, libzfs support is not needed in grub2 because you are not mounting the filesystem directly.
linux  /kernel-3.5.0-gentoo real_root=ZFS=rpool/ROOT/rootfs crypt_root=/dev/sda2 dozfs=force ro
initrd /initramfs-genkernel-x86_64-3.5.0

In /etc/fstab, make sure BOOT, ROOT and SWAP lines are commented out and finish the install.

You should now have a working encryped zfs install.

July 30, 2012
Sabayon on Amazon EC2 (July 30, 2012, 21:11 UTC)

During the last week, while I was enjoying my vacations, I’ve also had a lot of fun preparing a new EC2-friendly kernel (and sources) based off our kernel git repo (which is based on Linus’ kernel tree + some patches like the BFQ scheduler, fbcondecor and aufs3).

The outcome of my puzzle game (trying to figure out why an instance doesn’t boot on EC2 is like solving puzzles at times) is that sys-kernel/ec2-sources and sys-kernel/linux-ec2 (precompiled binaries) are now available on the sabayon-distro overlay and the Sabayon Entropy repository “sabayonlinux.org”.

As you may expect, I rapidly started to get bored again. For this very simple reason, and since I always wanted to have a fallback website/webservices infra ready on EC2 (in case of a disaster) I started cooking an EBS baked AMI, copycating the current Virtual Machines snapshots from our backup server.

As you may expect, I rapidly started to get bored once again. So, I prepared a molecule .spec file that automatically creates a ready-to-go ext4-based Sabayon Server filesystem image tarball ready to be dumped into a spare EBS volume. Once you have an EBS volume you just need to snapshot it and create the AMI from there (fyi).

As you may expect, I was getting bored of course. So I started preparing a “BuildBot” AMI that could be launched programmatically (say, from a cronjob) and once started (@reboot cronjob target is <3), attaches an existing EBS volume containing a Sabayon chroot, runs equo update && equo upgrade and other stuff, then detaches the volume, makes a snapshot, creates a versioned AMI.
Yes, boring stuff deserve a lot of bash scripting, can’t be otherwise. In this way, I can continuosly build updated Sabayon AMIs for EC2 without much human intervention (of course the BuildBot AMI mails back to me the upgrade result (both stderr and stdout)).
If anybody is interested in my “BuildBot” scripts, just drop a line here.

I don’t know yet where to go from here, but you may be interested in reading this wiki entry: “Sabayon on EC2“. Moreover, you may be also interested in knowing that the aforementioned filesystem image tarballs are already available on Sabayon mirrors, inside the iso/daily directory.

You can have a look at the currently available Sabayon AMIs here:


Sven Vermeulen a.k.a. swift (homepage, stats, bugs)
Kickstarting the Integrity subproject (July 30, 2012, 19:34 UTC)

Now that Gentoo Hardened has its integrity subproject, I started with writing down the concepts (draft – will move to the project site when finished!) used within the subproject: what is integrity, how does trust fit into this, what kind of technologies will we look at, etc. I’m hoping that this document will help users in positioning this project as well as already identify a few areas where I think we need to work on.

The guide starts with talking about hashes (since hashes are often used in integrity validation schemes), continuing towards HMAC (for authenticated hashes) and signed HMAC digests (for better protection of the cryptographic keys while verifying the integrity). It already talks a bit about trust (and trust chains) and how it works in both ways (top-down and bottom up – the latter especially when considering you are running services on platforms you do not manage yourself).

I will be working further on this, describing how the trusted computing group’s vision and the trusted platform module standard they developed fits into this as a possible implementation of trust validation (hopefully without getting to the religious part of it) as well as giving first highlights on other technologies we will look at as well.

July 26, 2012
Nathan Zachary a.k.a. nathanzachary (homepage, stats, bugs)

Recently, I posted about two screen lockers that I’ve used in the past (xtrlock and slock). There has been some great discussion about these lockers, and some potential security problems that come along with using them. One very prominent issue regarding using screen lockers without login managers was raised by a reader, and I want to address it in this separate post.

Just as some background information, many people prefer to use login managers (also known as display managers) in order to be greeted by a graphical login prompt. To use these managers, the X Window System must be started as one of the final steps of the boot process (either by setting the default runlevel to 5 in inittab, setting the display manager to start via the rc system / a daemon, or another method). Some people don’t like the idea of a login manager starting automatically at the end of the boot process, and would prefer to simply be greeted with a terminal login prompt. For those users, it is obviously still necessary to log in as a valid user, but then to start an X session (for their respective graphic environment), one must issue the startx command.

The problem with screen lockers and the startx method of starting Xorg is that it presents a large security flaw. I mentioned in the previous post that one can switch to a different virtual terminal (by using the CTRL+ALT+F# key combination) and log in as a different user. Unless that user can become root and kill the screen locker, though, there’s no problem. However, when Xorg is started using startx, a person can switch to the virtual terminal that issued the startx command, and just hit CTRL+C to kill it. They will then be at the prompt for the user that issued the command, and won’t have to log in. Oops…

A good workaround for this problem is to start Xorg and make sure that the terminal is locked if X is killed. This workaround relies on the package vlock, which is a terminal locking application. For it to work properly, instead of issuing the standard startx command, one needs to issue startx ; vlock. That way, if a person switches to the virtual terminal that started the X session, and hits CTRL+C, it will kill X, but that will automatically start vlock, and subsequently, present the person with nothing more than a login prompt. What’s more, that person will have to enter the password for the user that started the X session.

There might be more elegant methods for fixing this problem, including a script to disable virtual terminal switching when the screen locker is called, and I’ve been looking into such methods. If anyone has further suggestions regarding workarounds, or more permanent solutions, please feel free to comment.

Cheers,
Zach

July 25, 2012
Sven Vermeulen a.k.a. swift (homepage, stats, bugs)
Gentoo Hardened on the move (July 25, 2012, 22:41 UTC)

Gentoo Hardened is thriving and going forward. For those that don’t exactly know what Gentoo Hardened is – it is a Gentoo project dedicated to bring Gentoo in a shape ready for highly secure, high stability production server environments. This is what we live by, and why we do what we do. To accomplish this goal, we use a great community of developers & users that work on several subprojects: the implementation of kernel hardening features such as grSecurity, memory-based protection schemes such as PaX, toolchain updates to harden against buffer overflows and memory attacks, mandatory access control schemes such as SELinux and RSBAC.

In Gentoo Hardened we then integrate these technologies in Gentoo Linux so that it is usable by a larger community, well documented and supported. I’m myself heavily working on the SELinux integration & documentation aspects, and am hoping to contribute even further – but more about that in a minute.

Today, we had an online meeting where developers present their current “state of affairs” and the upcoming things they are going to work on. This is done about once every month in the IRC chat channel #gentoo-hardened on the freenode network. Of course, most of the developers are available on the chat channel on an (almost) daily basis.

Todays meeting gave us feedback on the following (and remind you, this is one month of volunteer-driven work)…

Toolchain

When we talk about the toolchain, we mean the set of tools and libraries needed to build a (hardened) system. We put most focus on the GCC compiler because it contains most of the changes we support (like stack smashing protection, position independent code/executable changes, etc.) but work on libraries like glibc and uclibc are on their way as well.

Zorry (yeah, I’m going to use nicknames here so you know who you’re talking to on IRC ;-) is working on getting our patches upstream (meaning that the main GCC development can incorporate our patches). Sending and working together with the main projects is very important as it provides not only continuity on the patches (once they are upstream, more people are maintaining the code than just you/us), but also gives a multi-eye view on the code: is it of high quality? Does it comply with the proper security guidelines? What about impact of the code on things we don’t or haven’t considered yet?

On the library part, blueness (one of our Gentoo Hardened developers and – imho – an expert in many fields) has been working on Hardened support on ARM (armv7a) with uclibc. He has put up stage4 files for armv7a softfloat uclibc hardened and is working on those for hardfloat. This means that ARM with uclibc+hardened or ARM with glibc+hardened are working – he has even tested an xfce4 desktop on ARM with uclibc and hardened toolchain.

ARM support is becoming more and more important in the technology field. Other major processor players like SPARC, Itanium, PowerPC, … are slowly seeing less and less market share, whereas ARM – albeit currently still a very small player – is rapidly gaining momentum. You all know ARM from the smartphones and other embedded-like platforms, but ARM on servers is coming faster than you expect. Being a simple platform with low energy consumption and good commercial backing (both on CPU level as well as platform support), we can see ARM becoming a major player on this – and Gentoo Hardened is actively working towards it.

Kernel

Within Gentoo Hardened, we support the grSecurity and PaX kernel patches for a more hardened Linux kernel. But this additional hardening can also sometimes interfere with the normal functioning of systems. To help users in their configuration quest, grSecurity allows users to select a few “prebuilt configuration types” in the kernel build.

Previously, these types where one of the following label: “virtualization”, “workstation” or “server”. Based on these labels, the security settings that did not negatively effect the functioning of the system were selected. Recently, the labels have changed into a question-based configuration: is it a server or not? will you use it for virtualization and if so, on host or guest? Is performance for you more important than security? These questions are now also integrated in our hardened-sources.

While working and testing one of the kernel settings (KERNEXEC – kernel non-executable pages, to protect non-code containing memory pages from being used to run (potentially hostile/injected) code from) in a virtualized environment, prometheanfire (another Gentoo Hardened developer) noticed a possible regression on the performance of guests if the host had KERNEXEC set. A severe performance hit is to be expected if the host processor doesn’t support hardware-assisted nested page tables (a method for supporting memory page virtualization), but this also seemed to occur on systems with nested page tables (/proc/cpuinfo flag ept for Intel, or rvi for AMD). So more testing (from others as well) is therefore needed to confirm and work on this.

SELinux

One of Gentoo Hardened’s subprojects (and one I’m most actively working on) is its support for SELinux or Security Enhanced Linux. It offers a Mandatory Access Control implementation for Linux, ensuring that users cannot change the security settings that an administrator has set (which is Discretionary Access Control if they can), but also enforce that services/processes can not be forced to do things they are not meant to do. This provides reasonable protection against things like remote code execution exploits, or just limit what an administrator wants particular processes to do. With SELinux, you can even define roles to properly identify and segregate tasks, providing a method for “segregation of duties” on OS level.

Anyway, as I said, Gentoo Hardened is actively working on SELinux integration. First of all is stages support (providing a small, deployable system unit that users can use to install a SELinux-enabled system) as currently, users are forced to switch to SELinux after having installed Gentoo, which is a multi-step approach. By offering stages, we can simplify the deployment of Gentoo Hardened SELinux. Currently, building stages works but requires some manual steps (labeling mostly) which need to be removed before we can automatically build stages. The next steps here are to see if we can build SELinux stages on non-SELinux systems (as all we need is to link the proper files with the SELinux-supporting libraries, which should work regardless of SELinux being enabled or not). The fact that users need to relabel their system during deployment is just a minor inconvenience (and a one-command fix, so easy to document too).

Another item of progression made is a SELinux-enabled (well, Gentoo Hardened grSecurity with PaX and SELinux enforcing enabled) virtual image called “selinuxnode”. This Qemu/KVM image is a simple Gentoo base installation but with those security features already enabled, allowing users to take a first look at SELinux before trying it out on their own system. But this image has the potential (and now roadmap ;-) to become much more:

  • Provide a play-ground for users to test things in. Try out hammering the SELinux policy, or reproducing potential issues before reporting them (to make sure they are easily reproduceable).
  • Become a Proof-of-Concept location for new enhancements: not only updates on SELinux, but also on other hardening measures and technologies that Gentoo Hardened can support. Implementing the technologies in the VM allow other developers to test and work on it without needing to sacrifice one of their own systems.
  • Become the main system for educational (course-like) documentation. If we develop HOWTO documents, using this VM as a base allows users to follow the instructions to the letter and try things out while keeping the documentation consistent. The documentation can, in the future, also contain instructions that users need to follow as a sort-of test. At the end of the test, a simple script can easily verify on the VM if the test was finished succesfully or not.

Even further down the road, it might evolve into a system for building appliance-like, hardened services based on Gentoo Hardened. But that’s a milestone too far for now. But you can always dream ;-)

On the SELinux policy development side, I’m recently focusing on two aspects: the change towards /run (which already required a few “urgent” updates and will probably need a lot more) as well as confining popular attack surfaces like browsers. Not many SELinux users run their browser in a confined space, but I personally don’t run anything in unconfined domains and feel that browsers are too popular in the security area to not put attention to. So I’m struggling to have the browsers (first focus is Chromium as that one has an open bug for it, and Firefox because that is my main browser platform) fully confined yet still flexible enough (using SELinux booleans) to support users that have other wishes on their browsers.

Speaking of policy development, in the meeting it was also brought forward to support a change of stabilization of SELinux policies from the standard 30-days towards a 14-day stabilization period. In most cases, this doesn’t harm users as policies are usually enhanced (allow something that was denied before) and less about reducing privileges (as it is quite hard to find out why a rule was enabled in the first place, hence our reluctant approach to “quickly” update policies). For such updates, We’re suggesting a 14-day stabilization period, while retaining 30 days for larger updates such as domain policy rewrites (which are sometimes needed if an application changes too much – think init and systemd – or when its segregated into multiple parts that each need (or can have) their own SELinux domain.

Finally, we gave a quick update on our status for upstream support (as I mentioned before, having patches supported and accepted upstream is very important for us): we have 116 changesets to the policy in comparison with the 20120215 refpolicy release (which is our “upstream”). Of those changesets, 45 have been accepted and implemented upstream, 12 are pending. 55 have not been sent yet (because they still need work or more documentation before they can be accepted) and 4 will not be sent (mostly because they are gentoo-only or deviate from upstream’s acceptance guidelines but fit in Gentoo’s approach).

grSecurity’s PaX

Blueness worked on the xattr pax support implementation (using extended attributes to store and manage the PaX flags, rather than using the ELF header changes used in the past) within Gentoo Hardened. This is now production-ready, so the proper tools will be made generally available shortly whereas the older method (mainly chpax) will be decommissioned in the very near future.

PaX markings allow the Linux kernel to toggle specific PaX settings on or off for processes so that the general state of the system can use the PaX protections while a very few set of programs that cannot work with these settings (often binary software or third party software, but some self-built software can have difficulties with PaX as well) can run without them (or with a lower set). This is much more flexible than an all-or-nothing approach. By using extended attributes, managing these markings can be done without modifying the binaries themselves. In Gentoo, proper support is also given through the paxctl-ng.eclass so developers can automatically set markings at deploy-time when needed.

Profiles

In Gentoo, users select “profiles” as a way to define the defaults for their system. Profiles define stuff like the default kernel, C library, specific USE flags, toolchain, etc. For instance, users that want to use a Gentoo Hardened system with SELinux on an x86_64 system with no-multilib (all 64-bit only) select the hardened/linux/amd64/no-multilib/selinux profile.

In the last few weeks, blueness has been working on the uclibc-related profiles (hardened/linux/uclibc/${ARCH}) using a clean slate. Gentoo supports profile inheritance, so you can “stack” one profile on top of the other. This is great for manageability, but when the profile is to support systems that are quite different from what Gentoo developers are used to, it makes sense to use a clean setup and start from there. And this is the case for hardened uclibc systems.

System integrity subproject

On this meeting the initial kick-off (after approval) was given of a new hardened subproject called system integrity. This project will focus on the implementation and support of integrity-related technologies such as (well, mainly) Linux IMA/EVM and its supporting userspace utilities and documentation. Integrity validation & enforcement is an important aspect of system security and, since I already work with SELinux, feel this is a natural improvement (since you need a MAC to enforce runtime security and use integrity to enforce detection and prevention of offline tampering).

We have great plans with IMA/EVM here, and can hopefully introduce the first few steps towards it in the selinuxnode virtual image soon ;-)

Documentation

Of course, technologies are great, but documentation is always needed (even if nobody reads it (sic)). I have been documenting hardening of some settings/services using the XCCDF/OVAL languages (part of the SCAP set of standards) since not only do they provide the means to generate guides (we can generate guides in every language, XCCDF is probably the least flexible of them all) but they also support the validation of the settings in an automated manner.

By using XCCDF/OVAL-supporting software such as Open-SCAP (app-forensics/openscap in Gentoo) you can interpret these guides in an unattended manner, generating reports on the state of your services compared to these guides, and even have specific profiles (one system uses a different set of hardening guidelines than another). Since Gentoo Hardened is about supporting secure & stable production environments, it is logical that we can offer best practices on how to handle Gentoo-provided/supported services. And by using these within the SCAP standard, the guides might even be leveraged further than a regular online HOWTO could.

And all that from one project?

Not really. Gentoo Hardened here plays several roles: integrator for technologies that are managed in other (free software) projects, and development for technologies or settings that are either specific to Gentoo or not available to the public to the extend Gentoo Hardened believes is needed. You must understand this is possible thanks to the tremendous effort that all these projects perform. Gentoo Hardened here plays the role that every Linux distribution has: making all these technologies and advancements fit in a way that the users can easily work with it – integrated and well supported.

Thanks to the free software nature though, Gentoo Hardened does more than what “commercial integrators” do when they deal with closed, propriatary software: it updates the code, improves it and brings it back for broader re-use. As such, it also acts a bit as development within those projects to assist them in their quest. And in my book, users are more likely to believe in an integrator that can react code-wise rather than using workarounds or “helping create a service request”.

The full excerpts of this meeting (the meeting minutes – well, actually an IRC chat log excerpt) will be sent out soon by the Gentoo Hardened project lead, Zorry. Big thanks to him (and the rest of the crew) to make all this happen! I love to be part of it, and hope I can remain so for a long, long time.

Edit: RSBAC, not grSecurity’s RBAC.

Greg KH a.k.a. gregkh (homepage, stats, bugs)
Ask a Kernel Maintainer (July 25, 2012, 19:27 UTC)

I've been writing an occasional "Ask a kernel maintainer" column on the lwn.net weekly kernel page. It's been a while since I last wrote one, so I figured it's time to start it up again.

So, consider this an open request for questions that you've always wondered, but never knew who to ask, or how to find the answer to, that you have had about the Linux kernel.

Note, any question that can easily be answered by reading either the Documentation/HOWTO or Documentation/SubmittingPatches or Documentation/CodingStyle files in the Linux kernel source code are not eligible. You should read them first before asking.

Please email them to me or post them in this Google+ thread, and I'll work over the next few weeks to answer them in the column.

July 24, 2012
Tomáš Chvátal a.k.a. scarabeus (homepage, stats, bugs)
Slowly going nuts (July 24, 2012, 08:24 UTC)

Gentoo dictionaries are slowly making me loose it… I got to 31 transfered myspell dictionaries which use upstream versioning scheme and have proper homepages. It still leaves behind 15 of those I didn’t find out anywhere or didn’t sort out the complexity of availale resources (eg 3 different tarballs to fetch from 3 different sites with insane versioning).

As it takes around 1-2 hours to just figure this s*it for one mutation PLEASE if you speak any of the following crazy languages help me out by figuring it for me and sending me ebuild (enough inspiration in the tree on how to write that darn ebuild) or at least instructions how to obtain the dict/hyph/thes set. The only help that I won’t be able to use is the one that uses the extensions.openoffice.org as the screwed up the downloads to have fancy IDs (i think I explained that in one of my previous blags) so it is not possible to track updates nor verify that we are downloading proper file (putting the version number into the provided files is for pussies right?).

Note that the English is a bit special friend. It has various mutations and each have its special versioning and homepage, so I will have to split that one out when I have free afternoon someday.

app-dicts/myspell-cy
app-dicts/myspell-en
app-dicts/myspell-ga
app-dicts/myspell-hr
app-dicts/myspell-hu
app-dicts/myspell-ia
app-dicts/myspell-mi
app-dicts/myspell-mk
app-dicts/myspell-ms
app-dicts/myspell-pl
app-dicts/myspell-ru
app-dicts/myspell-sw
app-dicts/myspell-tn
app-dicts/myspell-zu

Now for the more fun stuff. Libreoffice 3.6 is shaping up nicely and the 3.6.9999 ebuild should be safe to consume now as the 3.6.0 release is imminent (around 5th August). Try it with your unholy CFLAGS combos and report if something explode for you. There is still time to merge some build fixes. Remember that the test phase is still not fixed (I should just disable it for this release as I won’t prolly have time to fix it before 3.7) so run with FEATURES+-test if you enable those by default.

July 22, 2012
Josh Saddler a.k.a. nightmorph (homepage, stats, bugs)
new album: distance (July 22, 2012, 20:55 UTC)


distance by ioflowit’s been a few months since my last album. here’s the new one. four tracks, recorded one per day. these are the final pieces of my year-long creative one-a-day, which began in july 2011 and ended in july 2012.

this album was recorded and produced entirely with gentoo linux, using JACK timemachine and audacity, which are available in portage.

released 7/22/2012. free download. solo acoustic piano improvisations. four tracks plus wallpaper-sized album art. thanks for listening.

Sven Vermeulen a.k.a. swift (homepage, stats, bugs)
Dynamic transitions in SELinux (July 22, 2012, 19:11 UTC)

In between talks on heap spraying techniques and visualization of data for fast analysis, I’m working on integrating the chromium SELinux policy that was offered in bug bug #412637 within Gentoo Hardened. If you take a look at the bug, you notice I’m not really fond of the policy because it uses dynamic transitions. That’s not something the policy writer can do anything about if he can’t access the source code of the application though, since it means that the application is SELinux aware and will trigger transitions when needed.

So what’s this dynamic transitioning? Well, in short, it means that a process can decide to switch domains whenever it pleases (hence the dynamic part) instead of doing this on fork/exec’s. Generally, that sounds like a flexible feature – and it is. But it’s also dangerous.

Dynamic transitions might seem like a way to enhance security – the application knows it will start a “dangerous” or more risky piece of code, and thus transitions towards another domain with less privileges. Once the dangerous code is passed, it transitions back to the main domain. The problem with this is that the entire process is still live – anything that happened within the transitioned domain remains, and SELinux cannot prevent what happens within the domain itself (like memory accesses within the same process space). If the more risky code resulted in corruption or modification of memory, this remains regardless of the SELinux context transitioning back or not. Assume that some code is “injected” in the transitioned domain (which isn’t allowed to execute other applications) the moment it transitions back to the main domain which is allowed to execute applications, this injected code can become active and do its thing.

This is why I didn’t allow the original code (which ran chromium in the main user domain and used dynamic transitions towards chromium_renderer_t) to be used, asking to confine the browser itself within its own domain too (chromium_t) so that we have a more clear view on the allowed privileges (which is the set of the chromium domain and the renderer domain together). It is that policy that I’m now enhancing to work on a fully confined system (no unconfined domains).

If you want to know more about dynamic transitions, it seems that the blog post Subject & Object Tranquility, part 2 (and don’t forget to read the comments too) is a fine read.

July 21, 2012
Sven Vermeulen a.k.a. swift (homepage, stats, bugs)
Hardening the Linux kernel updates (July 21, 2012, 19:06 UTC)

Thanks to a comment by Andy, the guide now has information about additional settings: stackprotector, read-only data, restrict access to /dev/mem, disable /proc/kcore and restrict kernel syslog (dmesg). One suggestion he made didn’t make it to the guide (about CONFIG_DEBUG_STACKOVERFLOW) since I can’t find any resources about the setting on how it would made the system more secure or more resilient against attacks.

Underlyingly, the OVAL now correctly identifies unset variables (it previously searched for “is not set” strings in the kernel configuration, and now it searches for the key entry definition and validates if it doesn’t find it – e.g. “CONFIG_PROC_KCORE=” – since that matches both the definition not being there, or “# CONFIG_PROC_KCORE has not been set”).

How to test Kernel (*-sources) (July 21, 2012, 13:00 UTC)

In the past, a lot of people ask me how test a new kernel. This tip could help new arch tester.

First, emerge the new sources ( 3.4.5 is just an example, replace it with your ${version} ):
echo "=sys-kernel/gentoo-sources-3.4.5" >> /etc/portage/package.keywords
emerge -av =sys-kernel/gentoo-sources-3.4.5

Now go to kernel directory, try to enable all modules and check if them compile:
cd /usr/src/linux
make allyesconfig
make # don't forget to add '-j'

Might seem strange, but in the past, with allyesconfig, I found bug like this, not reproducible with normal config.

The next step is clean the past build and make your custom kernel.
make distclean
make menuconfig
make
make modules_install # if you use modules

Now try to boot with new kernel, and check if there are not bad message with:
dmesg

Now, try to reach a bit of uptime and if all is ok, please give a feedback.

This is a base guide to test {vanilla,gentoo}-sources. If you are testing a kernel with other/special features ( e.g. hardened/zen/tuxonice ), make sure that these features work perfectly.

July 20, 2012
Sven Vermeulen a.k.a. swift (homepage, stats, bugs)
Hardening the Linux kernel (July 20, 2012, 20:05 UTC)

I have moved out the kernel configuration settings (and sysctl stuff) from the Hardening Gentoo Linux benchmark into its own Hardening the Linux kernel guide. It covers some common hardening-related kernel configuration entries (although I’m sure I’m missing a lot of them still) as well as grSecurity and PaX settings (which is something the Gentoo Hardened project works on), and finally the system controls (sysctl) that are commonly suggested for a more secure system.

The overview of hardening guides now thus contains three guides: one for Gentoo, one for OpenSSH and one for the kernel. These ones were definitions I already had in the past so were “quickly” possible to write down. I’m going to look at BIND and DHCP next.

But simultaneously, I’m looking at Linux IMA/EVM support in the hope I can have this supported in Gentoo as well. Looks like a promising technology, and if I can get it working, it’ll definitely deserve its place within Gentoo Hardened!

July 19, 2012
Nirbheek Chauhan a.k.a. nirbheek (homepage, stats, bugs)
GUADEC 2012, A Coruña (July 19, 2012, 15:05 UTC)


This will be my first GUADEC, and I'm looking forward to it. Thanks to my employer Collabora for sponsoring this trip!



I'll be around from 25th evening to 30th morning. Hope to see you all there. :)

July 18, 2012
Sven Vermeulen a.k.a. swift (homepage, stats, bugs)
Hardening OpenSSH (July 18, 2012, 20:20 UTC)

A while ago I wrote about a Gentoo Security Benchmark which would talk about hardening a Gentoo Linux installation. Within that document, I was documenting how to harden specific services as well. However, I recently changed my mind and wanted to move the hardening stuff for the services in separate documents.

The first one is now finished – Hardening OpenSSH is a benchmark informing you how to potentially harden your SSH installation further. It uses XCCDF/OVAL so that users of openscap (and other compliant tools) can test their system automatically, generating nice reports on the state of their SSH configuration.

For now, the SSH stuff is also still part of the Gentoo document, but I’ll move that out soon and refer to this new document.

Hardened Gentoo’s purpose is to make Gentoo viable for highly secure, high stability production server environments. Hence, hardening documents
should be one of its deliverables as well. So, dear users, do you think it is wise for the Gentoo Hardened project to also focus on delivering hardening guides for services? If so, I’m sure we can draft up others…

Jeremy Olexa a.k.a. darkside (homepage, stats, bugs)
Gentoo Miniconf / Linux Days 2012 (July 18, 2012, 14:25 UTC)

I’ll be there.

July 17, 2012
Ole Markus With a.k.a. olemarkus (homepage, stats, bugs)
PHP 5.4 about to be stabilised (July 17, 2012, 18:30 UTC)

PHP 5.4 has been in the tree for quite some time now, without any major bugs. Personally I have been using it on my development box since it went stable upstream and everything has been working just fine. PHP 5.4 has been in ~arch since 5.4.0 as well, so the upgrade path should (hopefully) be well-tested. So it is about time that PHP 5.4 gets a stable version in Portage!

The reason I have been holding off for so long is the lack of support from certain key extensions. The most important, in my opinion, is APC, which I personally need in place before using PHP in production. Unfortunately there are several outstanding issues with the current version of APC for PHP 5.4, and there is no ETA for when a stable version will be released. Those who can may look into XCache, which do have a working PHP 5.4 version.

Another extension that someone might miss is Suhosin. The Suhosin patch is also missing.

July 16, 2012
Nathan Zachary a.k.a. nathanzachary (homepage, stats, bugs)
Screen lockers xtrlock and slock (July 16, 2012, 23:21 UTC)

For many years now, I have used a very simple screen locker called xtrlock in order to stop others from accessing my systems whilst I’m away from my desk. Some time ago, I switched from using Gentoo on my Samsung NC10 netbook to using Arch. Though I prefer Gentoo, it just didn’t make much sense to compile everything on that poor Atom N270 processor (think Chromium or LibreOffice). Anyway, Arch does not have xtrlock in their repositories, likely because it has been abandoned upstream since 2010 (although the Debian homepage for the package shows an update to version 2.2 as of June 2012). So, I needed to find an alternative package for locking my screen.

Seeing as I am a minimalist, I wanted something incredibly lightweight without a bunch of features that I will never use or dependencies linked to the libraries of some particular desktop environment. Through some quick searching, I found slock, which is arguably even lighter and featureless than xtrlock. Xtrlock displays a little blue lock icon in front of the active desktop, only allowing for cursor movement until one enters the password of the user who invoked it. Slock, on the other hand, doesn’t even show the desktop or an icon. Instead, it shows a black screen. Similar to xtrlock, slock requires one to enter the password of the user that started the application in order to see the desktop again. So, both applications are very similar in nature and execution.

Both applications also have a similar “flaw,” which likely won’t have much of an impact, but is worth mentioning. When the screen is locked using either application, one can switch to a different virtual terminal (by using the CTRL-ALT-F# combination for the desired virtual terminal) without entering the password of the user that started the locking application. Now, that user can log in to the system, but cannot kill xtrlock or slock unless they can become root. However, it does pose a bit of a security concern in some use cases that don’t really apply to my situation. If you can think of some other possibilities, feel free to leave a comment here, and I’ll further investigate.

So, which application is better? Seeing as they both accomplish the same task, they are both lightweight and unobtrusive, and they are both available via Portage, it would seem to be a stalemate. However, the two each have one exclusive plus, respectively. Xtrlock still shows the display. That means that if you are in an environment where you need to have an application (like ping or watch -n 1 'netstat -tupan' running even whilst you are not directly in front of your computer, it will still run and you can still see it. That may also be an unlikely use case though. Slock, by only showing a black screen and not indicating any type of other activity, may be an added layer of security through obscurity. In either case, both applications are relatively similar.

Cheers,
Zach

EDIT: Be sure to view the update to this post for more information about a security problem with startx and screen lockers.

Andreas K. Hüttel a.k.a. dilfridge (homepage, stats, bugs)
Gentoo in c't magazine (July 16, 2012, 21:39 UTC)

For the German speakers around here, today's edition of c't magazine (that's the company that people from UK/USA may know as "The H") includes an introductory article on Gentoo Linux: "Made to measure - Gentoo Linux: source code and rolling releases". So, go to your newsagent and grab it while it's hot! :)

Sven Vermeulen a.k.a. swift (homepage, stats, bugs)
Updated Gentoo Hardened/SELinux VM image (July 16, 2012, 16:31 UTC)

I have updated the Gentoo Hardened/SELinux VM image, available on the mirrors under experimental/amd64/qemu-selinux.

The new image now asks for the keyboard layout, has a short DHCP timeout value (5 seconds) and provides the nano editor. If you plan on running the image using qemu, please use -cpu kvm64 to use a 64-bit virtual processor.

July 13, 2012
Nathan Zachary a.k.a. nathanzachary (homepage, stats, bugs)

Apache has two main logs at the vhost level, and those are the access_log and error_log. These two logs keep track of just what you might think–visitor information for each vhost, and any errors encountered, respectively. Though Apache has a lot of built-in customisation abilities regarding these logs (including the format of each, the log location, et cetera), it does not have much in the way of organising them. Before delving into the solution to that problem, let’s look at some of the customisation that can be done for each of these logs within Apache itself. For the access_log, one can choose what level of information is logged by setting up a LogFormat directive such as the one below:


LogFormat "%h %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined

What does this directive actually do? The first portion–LogFormat–is the Apache directive itself, and as such, instructs Apache that all of the options thereafter will be related to your desired formatting of its logs. Each element within the quotation marks instructs Apache to log certain elements, and here’s what each element listed above is:

  • %h – The host of the remote connection (the IP address of the visitor)
  • %u – The user that is trying to connect to a resource protected by HTTP Authentication (like Apache BasicAuth)
  • %t – The timestamp of the activity (in the default format of DD/MMM/YYYY:HH:MM:SS GMT+/- offset)
  • %r – The request line, which contains the method (i.e. GET / POST), the resource requested, and the protocol used
  • %>s – The HTTP status code that the user received for that resource (200 OK, 404 Not Found, et cetera)
  • %b – The size (in bytes) of the requested resource
  • %{Referer}i – The site from which the user came to request this resource
  • %{User-agent}i – Information about the user’s browser (e.g. Firefox, Chromium) and their OS (e.g. Windows 7, Linux, Android)

The last portion of the LogFormat directive is the nickname, which in this case is “combined.” That nickname can be referenced in conjunction with the CustomLog directive in each vhost in order to call the particular format. For instance, if I had a particular vhost for which I wanted this LogFormat, I would reference it with a line like:


CustomLog /var/www/domains/somedomain.com/host/logs/access_log combined

Where the first field (CustomLog) is the directive itself, the second field is the location of the log, and the third field is the nickname of the LogFormat that we previously defined.

One thing that Apache doesn’t have built in regarding logging, though, is organisation of the logs based on a time frame or similar. There is a programme that, even though it hasn’t been updated for some time now, works really well in achieving this goal. That programme is Cronolog. Many distributions might not have it in their repositories, and in those cases, one needs to compile it from source. However, Gentoo does offer it via Portage. Once you have it installed (either from your distribution’s package manager or compiled from source), configuring Cronolog is quite simple and straightforward. All that needs to be done is a slight change of syntax in the CustomLog directive from above. Here’s an example:


CustomLog "|/usr/sbin/cronolog /var/www/domains/somedomain.com/host/logs/%Y/%m/access_log" combined

Let’s break down that syntactical change piece by piece. The first field remains the same, as it is the Apache directive of CustomLog itself. The second field is now encased in quotation marks, and features the pipe to start. The pipe is essentially taking the logged information that Apache is gathering and passes it to the programme mentioned thereafter; namely, Cronolog (which is, by default, located at /usr/sbin/cronolog). Thereafter, the same log location is called, except for one key difference: the %Y and %m folders are now in the path. As you may have guessed, Cronolog creates a folder for the year (%Y), and subfolders for each month (%m) within it. When either of those stamps change (in this case, each month), new folders / subfolders are created, and Cronolog instructs Apache to log to the access_log file within the appropriate subfolder.

Pretty neat, and easy to set up eh? I hope that you feel empowered to use Cronolog within your Apache environment.

Cheers,
Zach

July 12, 2012
Andreas K. Hüttel a.k.a. dilfridge (homepage, stats, bugs)
Lab::Measurement 3.00 released (July 12, 2012, 17:56 UTC)

I'm happy to be able to announce a first real release of the Lab::Measurement Perl package, providing a platform for measurement control with Perl.

Lab::Measurement is based on the packages Lab::VISA, Lab::Instrument, and Lab::Tools started by Daniel Schröer in 2005. Many people have contributed in the meantime, amongst others in roughly historical order Daniela Taubert, David Kalok, Florian Olbrich, and Alois Dirnaichner. The efforts of the last year have focussed on a general modularization, originally driven by a certain frustration with National Instruments NI-VISA support on Linux. Now, the hardware driver backend can be exchanged transparently, making measurements both with NI-VISA and with e.g. LinuxGPIB or the operating system serial port drivers on Linux and Windows possible.
Since VISA does not form a central part or even requirement anymore, the original use of Lab::VISA as name for the entire package became impractical, and we've decided to switch to Lab::Measurement instead. As version numbers of all components should still increase monotonously, our first release of the code rewrite then actually ended up as Lab::Measurement 3.00.

For downloads and documentation, including installation instructions for Linux and Windows and examples, visit the homepage of the package, http://www.labmeasurement.de/. Of course, if you're using Gentoo, the package is readily available in the main portage tree as dev-perl/Lab-Measurement.

Not all device drivers have been ported to the new internal architecture so far, but work is progressing swiftly. In the Regensburg nanophysics groups, we're using the new code already all the time in measurements at three different cryogenic setups. More drivers, bugfixes, and improvements are present in Git master. If you're willing to hack, I can only recommend that you give it a try. Contributors are always welcome; feel free to clone our git repository on Gitorious.

July 11, 2012
How to test a library (July 11, 2012, 16:21 UTC)

This article should be useful for every arch tester that ask how properly test a library.

Today we see a case like boost. The firsts steps will be:

  1. Emerge the new boost version
  2. Do a multiple compile test changing the USE
  3. Make sure the new boost is set as default: eselect boost list

Now, to make sure to don’t break the tree, you will compile all stable packages that have boost as DEPEND. To do this task we will use the reverse-dependencies.py script from the arch-tools repository ( thanks to Paweł Hajdan to make it ).

How reverse-dependencies works? Is very simple, follow this example:

touch boost_in;touch boost_out
echo "=dev-libs/boost-1.49.0-r1" >> boost_in
echo "=dev-util/boost-build-1.49.0" >> boost_in
python reverse-dependecies.py -i boost_in -o boost_out

Let me explain a bit.

First we have created 2 files;

  • in the first will go the package that needs to check.
  • in the last will go the package found by the script.

Yes in this case boost-build is not useful, but this example should tell you that you can put more than one package in the input file(boost_in). With the last command we have now a boost_out structured in this manner:

# One of the following USE flag combinations is required:
# boost
sci-mathematics/singular

That obviously means that you need to enable boost USE to make sure that sci-mathematics/singular use boost.

 

Now you need to compile all of packages in boost_out list and if you see failure related to boost you need to create a new bug on our bugzilla and make it as a blocker for boost stabilization.

July 10, 2012
Donnie Berkholz a.k.a. dberkholz (homepage, stats, bugs)
How to recruit open-source contributors (July 10, 2012, 21:49 UTC)

I just posted a video and write-up on how to recruit open-source contributors over on my RedMonk blog. It’s based on my years of experience as admin for Gentoo’s involvement in the Google Summer of Code, where I’ve greatly increased our ability to recruit students as long-term developers. Check it out.


Tagged: communication, culture, gentoo, gsoc

Sven Vermeulen a.k.a. swift (homepage, stats, bugs)
Gentoo Hardened/SELinux VM image (July 10, 2012, 19:27 UTC)

A few weeks ago, I pushed out a VM image (Qemu QCOW2 format) to the /experimental/amd64/qemu-selinux/ location in our mirrors. This VM image (which is about 1.6 Gib large decompressed) provides a SELinux-enabled, Gentoo Hardened (with PaX and other grSecurity security settings) base installation. Thanks to the Qcow2 image format, only the used 1.6 Gib of data is taken on your disk, even though the image is made for a 50 Gib deployment).

The purpose of this image is, eventually, to allow users to test our Gentoo Hardened with SELinux in a virtual environment, offering decent isolation (so you can mess things up if you want, it doesn’t hurt your own system). I’m also contemplating of providing more serious SELinux-focused course material (self-teaching stuff) based on this image, so that users can learn about Gentoo Hardened (and SELinux) in a structured manner.

But before all that, I first need to see if the image is usable by most people:

  • Does it boot? It is an amd64 image for the Qemu KVM64 CPU, but the kernel uses paravirtualization for disk and network access, and I don’t know if that’s a safe bet to do or not. People that know KVM know that the paravirtualization support is needed for decent performance, but I’m not sure if it still makes the images sufficiently portable or not.
  • Does it work? The build is done based on my own systems, but these are all built in a similar fashion (and use binhosts to simplify deployment) so in effect, I can only test the images on a single system type (multiple, but they’re all the same, so doesn’t matter).

If I can get some comments on this (it boots, it doesn’t boot, it sucks, …) and can work out things, I hope I can have the images better for all of us.

Edit: yes, keyboard layout is azerty, not qwerty. So your rootpass will be rootpqss. Updates-are-a-comin’

Donnie Berkholz a.k.a. dberkholz (homepage, stats, bugs)

I gave an introductory talk on Gentoo at a local BarCamp called MinneBar a couple of months back, and the videos were just posted online. The sound isn’t perfect but it’s perfectly understandable. Oddly, this is the first time I’ve ever given a formal talk on Gentoo in nearly 10 years of working on it.

The slides are pretty tough to read from the video, so I also uploaded them to Slideshare. I updated and heavily customized the same “Intro to Gentoo” slide deck that’s been floating around for years. It still could stand to lose a whole lot more text, and hopefully I can optimize it further if I give it again.


Tagged: communication, gentoo, pr

July 09, 2012
Mike Pagano a.k.a. mpagano (homepage, stats, bugs)
Kernel Maintenance Help Part 2 (July 09, 2012, 23:32 UTC)

Many years ago, the Gentoo kernel lead asked for help.  2 people responded.  I was one of them.  So I figured if I got 2-3 people and one stuck around, I would be in good shape.

This time, I got 26 people responding offering their help. Four of which are currently Gentoo developers. First, I’d like to thank everyone that responded. I was extremely surprised.

Now, since I cannot mentor 22 people at the same time I need to think of a plan.  I’m hoping to lean on the Gentoo developers, as they are already developers and will need a fraction of the instructions that the others will.  This is not a slight on anyone’s ability, just the whole Gentoo Way(tm) thing will not have to be taught to these folks.  They can also commit todayfor eclass changes and bump kernels as needed. Also, if everything goes well, they can help me mentor who from the other 19 want to follow through the entire process.

I’m going to try to get everyone started triaging bugs and then go from there. Thanks again, everyone. Expect an email from me very soon.

 

July 08, 2012
Markos Chandras a.k.a. hwoarang (homepage, stats, bugs)
Gentoo Screenshot Contest 2012 (July 08, 2012, 12:11 UTC)

Same as the previous year, and the year before, we are doing it again! Submit your pretty screenshot and gain a place in the Hall of Fame.

July 07, 2012
New category: arch testing (July 07, 2012, 22:07 UTC)

I added recently a new category for this blog: arch testing.

 

Since in the years I’ve ‘gained’ a long experience with arch testing I think would be great collect a series of tip for the current and future arch testers.

Obviously the posts in this category will be related primarily for amd64, but x86 guys could take many suggestions from non-amd64 specific posts

Hans de Graaff a.k.a. graaff (homepage, stats, bugs)
More details on the ruby 1.9 migration (July 07, 2012, 09:07 UTC)

Based on questions recieved so far I have added a page to the Gentoo wiki with more details on the ruby 1.9 migration. Let me know if you have more questions or feel things are still unclear, and I can elaborate the article further.

July 06, 2012
Mike Pagano a.k.a. mpagano (homepage, stats, bugs)
Looking for help with kernel maintenance (July 06, 2012, 13:57 UTC)

Once again, the Gentoo Source kernel team is looking for one or more people to help out with Gentoo-sources maintenance. Currently, I am the sole maintainer of our primary supported kernel and from the email complaints I have been receiving lately, I am just about treading water.

Maintaining the kernel consists of a few jobs:

- Bumping Gentoo sources to keep consistent with upstream releases. I can only support three versions (used to be 2 version supported, with more people)  of the kernel at any time. Right now I try to support 3.0, 3.2 and 3.4. When 3.5 comes out, one of those will drop off.

- Kernel Bugs. At the least, I try to help identify patches from upstream to back port to supported kernels to solve issues. Actually digging into kernel code to solve issues is the most time consuming part of the job. Unfortunately, my time constraints lately don’t allow much time for this anymore. The time to dig deeply and solve these issues is always an unknown, and better steered to keeping up to date kernels available for Gentoo as I am the only person.

I would like someone who at least thinks she/he is going to stick around for awhile. The last few people who were on the kernel team lasted around 6 months.

I’m going to steal an old developers call for help:

I’m looking for someone with at least:
- Interest in kernel stuff, or a desire to become interested
- Time to put towards the tasks
- Enthusiasm to ask lots of questions rather than let stuff sit around
- Basic experience with Bugzilla
- Basic kernel experience (i.e. you can compile your own)

Having knowledge of kernel internals or experience with kernel hacking are NOT requirements because if you have time, interest and ask a lot of questions then these will come anyway. A lot of the work doesn’t involve technical stuff, plus I was certainly very clueless about all this when I originally got involved a few years ago.

Being an existing Gentoo developer is not a requirement. Most of the work is done on Bugzilla and via email. This may be a good opportunity to get involved with development and later become a Gentoo developer for those that are interested.

It’s an enjoyable task, you get to interact with a lot of very intelligent people upstream and you end up learning a lot.

If you think you’re interested, you can email me or find me on IRC at #gentoo-kernel

Repoman-check before file stable request (July 06, 2012, 10:10 UTC)

I already recommended, time ago, in gentoo-dev mailing list to check with repoman before file stable request. Why?

The reason is very simply; is only a waste of time try to keyword and receive a bad response from repoman because missing some other packages with stable keyword.

So, as reminder, you need to do:

STABLE_KEYWORDS="amd64 ppc x86"
ekeyword ${STABLE_KEYWORDS} ${your_ebuild}
repoman manifest
repoman commit -p -m "nothing"

This sample of code can be automated with a little script.

If anything goes bad, you will see the list of package needed for this stabilization.

NOTE: be careful with ekeyword because will happen bug 399061.

July 04, 2012
Tobias Klausmann a.k.a. klausman (homepage, stats, bugs)
Why aren't we helping? (July 04, 2012, 17:28 UTC)

As long as I can remember, HowTos, blog posts and books have recommended to compile kernels (or, actually, any piece of software) as a normal user. That is to say: do not compile the kernel as root.

Obviously, if you're going to install the kernel you've just built, you have to become root. The actual compile, however, does not need to be done as UID 0.

The main reason for this is safety (note: not security, I'll get to that in a bit). Minimizing the amount of time logged in as root is a Good Thing, hence software like sudo. This is of course because you might fat-finger a command. But also because the software you use might be buggy and run amok. I vaguely remember some luminary relating how at one point in the distant past, the kernel build system would wipe out your filesystem (from /) if run as root. Unfortunately, I am unable to come up with any reference for that. True or not, it is/was a possibility.

So why is it not a security matter? Well, if the kernel source (which the build system is part of) is compromised, you are screwed anyway. The same goes for gcc: something you compile will be run as root. And from then on, well, go read Ken Thompson's "Reflections on trusting trust" for the details.

Some argue it might actually be bad to store the sources in a way writable by anyone but root (your user account being compromised is more likely due to you using more software like browsers and IRC clients with it).

So the root question is: do we still recommend not compiling as root? If not, we need to stop giving advice to the contrary. It might take a while, since there is a lot of cargo-culting going on in these matters. If we do recommend compiling as a user, the question is why we don't encourage doing so. Heck, we're not even helping users with it. And if we choose to change that: what is the best way is to not compile as root?

The steps still requiring UID 0, that is make install modules_install and modifying the boot loader configuration, can be easily done with sudo and its oft-forgotten sidekick sudoedit.

The heart of the matter, however, can be tackled in several ways:

  1. Change ownership of the source tree to a UID of the user's choice. This would usually be the main user of a given machine, i.e. the person who until now used su to become root and then compile the kernel. Advantage: once the distributions support this in some manner, it's very simple. Disadvantages: as outlined above, some perceive this as a security risk. Also, it's something you need to configure as a user. The distributions would probably default to using UID 0 if unconfigured. Thus, due to inertia, basically nothing would change.
  2. Like option #1, but use a UID of a role account. That is, not a regular user that has a human associated with it. This would have the advantage that a buggy browser would not directly provide access to the kernel sources. Also, it doesn't need to be configured, which is a big plus. People who are used to running the compile as root would not need to change their workflow (whether this is good or bad is debatable). The compiling account would not have a password (meaning you can only sudo or su to it). The install phase could be solved by either giving the compiling user write access to the appropriate locations/files or by allowing access through sudo. In "paranoid mode", the user would need to drop back to their main account and sudo to UID 0 for the install step.
  3. The kernel build system allows writing all output to a different directory (also getting the configuration from there) using the O= mechanism of the command line or KBUILD_OUTPUT environment variable. The user would set either to a location in $HOME and then use sudo to install from there. This has the advantage of keeping the main source location clean (which is the main reason the variables exist in the first place). It also allows users to have separate builds without clobbering each others binaries. The latter advantage is minimal, though: individual users would usually have their own trees anyway in that scenario. In essence, O= and KBUILD_OUTPUT do what some build systems (e.g. CMake) already do: separate sources and compilation output.
  4. The most radical approach is to drop the source files from the distribution package systems entirely. Arguably, carrying source trees is not their main purpose. Also, most users (of binary distributions) should just use the distribution kernel and be done with it. The source distributions like Gentoo could provide a tool to quickly download the latest sources to a directory of the user's choice. Power users could always download and unpack themselves. The disadvantage of this (for source distributions) is that some packages need build-time access to the kernel tree. A solution to this could be a symlink like /usr/src/linux that the user has to manage on their own, possibly redirecting through one in their home directory. The randomness this would cause would also make it trickier for a would-be attacker to compromise the kernel source. Note, however, that this is easily compensated for by an even slightly determined attacker.
  5. As a side note/merge of downloading tars (thanks to Michał Górny for pointing it out), there is the possibility of having your own checkout of the tree. Aside from the disadvantages of the "power user" approach, this means keeping around 1.4G of data (as of currently) vs. 512M for 3.4.4. In the days of multi-terabyte disks, this might not seem like much, but it also means you have to manually check for new versions. Aside from that, not everybody wants to learn how to use git (it is trivial for this use case). One benefit is that you only have to recompile what has changed since you last did a checkout from upstream.

And that are the options I can think of. Feel free to suggest more options if you have them. As usual, comments by email please. You can also yell at me through IRC (Blackb|rd@Freenode) or G+ (I used my real name to register).

Note that while I'm a Gentoo dev, I prefer solutions that all distributions can adopt.

July 01, 2012

In this post I am going to present a quick guide to set up a basic environment to test and develop GRUB 2 themes on Gentoo Linux. Its core feature is the use of virtualization so you restart virtual hardware rather than physical one.

Ingredients:

  • KVM (or QEMU) — i.e. package app-emulation/qemu-kvm or app-emulation/qemu
  • GNU parted — package sys-block/parted
  • kpartx — from sys-fs/multipath-tools
  • GNU GRUB 2 — sys-boot/grub:2

Despite care and best intents: For what comes next, NO WARRENTY of any kind! sudo and root permission stuff is involved.

First, let’s install the required software:

$ sudo GRUB_PLATFORMS='pc' emerge --update sys-boot/grub:2 \
    sys-fs/multipath-tools sys-block/parted app-emulation/qemu-kvm
[..]

Now, let’s create a sparse, virtual hard disk of 500MB in size and create a partition table with a single partition covering all available space. We use bash syntax to do the math.

$ touch grub-theme-disk

$ truncate --size=$((500*1024**2)) grub-theme-disk

$ /usr/sbin/parted grub-theme-disk mklabel msdos
WARNING: You are not superuser.  Watch out for permissions.

$ /usr/sbin/parted grub-theme-disk mkpart primary ext2 0% 100%
WARNING: You are not superuser.  Watch out for permissions.

Next, we make a block device for that partition and format it as ext2. We also store the location of the whole disk and the partition in dedicated variables for re-use.

$ sudo kpartx -p p -a -v grub-theme-disk
add map loop0p1 (254:9): 0 1021952 linear /dev/loop0 2048

$ GRUB_PART=/dev/mapper/$(sudo kpartx -p p -l grub-theme-disk \
    | grep -oE 'loop[0-9]p1')

$ GRUB_DEV=$(sudo kpartx -p p -l grub-theme-disk | grep -oE '/dev/loop[0-9]')

$ echo "${GRUB_DEV}, ${GRUB_PART}"
/dev/loop0, /dev/mapper/loop0p1

$ sudo mkfs.ext2 "${GRUB_PART}"
mke2fs 1.42.4 (12-June-2012)
[..]
Writing superblocks and filesystem accounting information: done

Now we mount the file system and create a minimal GFX GRUB 2 config in it using theme “starfield” that comes shipped with GRUB 2. For the menu, two dummy entries to restart and shutdown the machine are used.

$ mkdir grub-theme-disk-root

$ sudo mount "${GRUB_PART}" grub-theme-disk-root

$ sudo mkdir -p grub-theme-disk-root/boot/grub2/

$ cat <<"GRUB_CFG" | sudo sh -c 'cat > grub-theme-disk-root/boot/grub2/grub.cfg'
set theme=$prefix/themes/starfield/theme.txt
insmod all_video
insmod gfxterm
insmod png
terminal_output gfxterm
menuentry Reboot { reboot }
menuentry Shutdown { halt }
GRUB_CFG

We are ready to install GRUB 2. That includes copying files to /boot/grub2 (e.g. the starfield theme) as well as writing the bootloader to the master boot record of the virtual disk file (or more precisely the related loop device). We need to flush the write cache using the “sync” command so we do not boot from half-flushed data in the next step.

$ sudo grub2-install --boot-directory=grub-theme-disk-root/boot "${GRUB_DEV}"
Installation finished. No error reported.

$ sync

At that point, our disk image is ready to be booted as hard drive by KVM (or QEMU):

$ sudo qemu-kvm -hdd "${GRUB_DEV}"

You should see something like this (click to enlarge):

Now for the most important part:

If you do make a theme please make sure the overall theme is legally sound! For instance that means:

  1. If you use the original, rendered “g” Gentoo logo, the related files have to comply with the CCPL-Sampling-Plus-1.0 license.
  2. If you use Larry the cow graphics, the theme has to comply with the CC-BY-SA/2.5 license.

This can hardly be over-emphasized. If you fail to respect licenses properly Gentoo will not be able to include your theme anywhere, really. Other than that, happy theming! Feel free to post links to your Gentoo GRUB 2 themes in the comments below.

For more graphical building blocks and logos that you might want to use, please check out the Gentoo Artwork page and the vector remake of GDM 2.x background “gentoo-cow”.

The theming file format of GRUB 2 is described in detail in the official GRUB manual.

June 29, 2012
Sven Vermeulen a.k.a. swift (homepage, stats, bugs)

The Gentoo Wiki folks have started a great idea (and immediately set a nice milestone), namely the Gentoo Wiki Summer of Documentation. By september, they want to double the amount of articles on the wiki.

I’ll surely help out and participate where I can, and perhaps we can even go far above the targeted 500 articles!

June 27, 2012
Aaron W. Swenson a.k.a. titanofold (homepage, stats, bugs)
Introducing slimlock: Unholy screen locker (June 27, 2012, 15:07 UTC)

I have just added a new package to the tree: slimlock. slimlock is a lightweight screen locker that uses the same interface presented by SLiM.

For you GitHub enthusiasts, you can follow the development of it and perhaps contribute back to the project. There are a couple seemingly simple things to fix, if you’re familiar with X11 and C++.

slimlock is probably the quickest locker I’ve used yet. I just press the padlock hotkey on my keyboard, blink and it’s locked. Same goes for unlocking. It’s everything I expect from it given the performance of SLiM.

Thanks Mr. Joel Burget!

June 26, 2012
Patrick Lauer a.k.a. bonsaikitten (homepage, stats, bugs)
The Janitor's Manifesto (June 26, 2012, 05:44 UTC)

(as there are Council Elections again here's my Manifesto. Or something almost, but not completely unlike it)

Most of what I do is cleaning up. Fighting entropy. Removing bugs so we can have the best distribution there is. And because there just never are enough hours in a day I like to find replacements for me. Recruit new people to do what I did so I can find the next problem.
I wont stop doing that.

Most of the things we do are outside the sphere of influence of the council. We get at least 90% of our Gentoo-work done without needing anyone to nudge us in the right direction. But it's the rest of our troubles that needs lots of discussion and motivation to find the most effective solution to our issues.

I'm an opinionated muppet. But my opinions are usually based on experience. And when I see a bad idea I'm not going to tolerate it because it might upset your feelings. Deal with it ;) But I guess people are aware that I'm, uhm, "polarizing". And getting me into the Council will make it a lot easier for me to punch stupid ideas until they go away. Like, say, the zombie GLEPs 54/55 that have been summoned back for about 2 years until people slowly got the idea that they won't be tolerated. (Amusingly we now finally have the "EAPI at beginning of file" rule that obsoletes it. So it goes.)

Independent of what you vote I'll continue doing what I do - try to recruit people, do random build experiments across the tree for fun, file bugs ... it won't get boring soon. So much to do ... but it'll be a tiny bit easier for me if I'm councilerated.

Here's a rough list of things that would be nice to have, in approximately ascending order of difficulty:

  • deprecate EAPIs so that only 0 and latest are in use
  • Signing policies - keyring, key type, etc. Make it make sense.
  • PR: make people notice us again. GWN revival, articles for LWN, etc.
  • Tools and automation: Make it easy to be lazy. Get more done in less time
  • Recruitment: assimilation of derived distros (pentoo, TinHat, Sabayon, funtoo, calculate) and others (Slackware, OpenSUSE, FreeBSD ?)
  • Recruitment: make it easy for people to contribute, and as soon as they do don't let them leave
  • Stop the Windowsification (offline updates?!) and MacOSification (systemd, /usr move, initrd as everything, trollolololooooo)
  • Be Awesome

June 24, 2012

It has been on my personal todo list for a while to remake the background of the “gentoo-cow” GDM 2.x theme in vector format. So I took some time to work on that today. The result is an SVG file and a bunch of PNG renderings (in many resolutions, ratios 4:3, 5:4, 8:5 and 16:9), now part of the Gentoo Linux Wallpapers section.

With that remade vector version you ca

  • make razor-sharp renderings for any resolution you like
  • adjust colors for yourself with high quality results despite little effort
  • distribute any derivative works under CC-BY-SA/2.5

Maybe someone likes to base a (legally sound) GDM 3.x or GRUB 2 theme on it… ?!
If you need help setting up an efficient GRUB 2 theming playground, please get in touch.

Download SVG

Sven Vermeulen a.k.a. swift (homepage, stats, bugs)
Had to edit /etc/init.d/root (June 24, 2012, 13:38 UTC)

For some reason, I had to edit my /etc/init.d/root file to use “mount /dev/root -n -o remount,rw /” instead of the standard “mount -n -o remount,rw /”. Without this, it failed to remount the root file system in a read-write mode, which is of course not that funny…