Planet Exherbo

December 19, 2014

Mike Kelly

Any good perl or FreeBSD books?

I'm starting to learn perl, and I've found the perldoc intro/tutorial stuff to be pretty useful, but I'd like to get a good printed book or two to read through and use as a reference.

Similarly, while I'd say I'm pretty *NIX savvy, I'm not too familiar with some BSD-isms, particularly where they differ from Linux. Are there any good books out there to help with the transition from Linux to FreeBSD? (No, I'm not abandoning Linux... it's just that my current employer used FreeBSD for many things.)

Any suggestions?

by Mike Kelly at December 19, 2014 08:16 AM

Encrypting (almost) your entire hard drive with dm-crypt (LUKS) and lvm2, Part 2

Six months ago I posted an outline for encrypting your system with LUKS. Well, I figure it's about time for me to write up how to actually go about it. In this post, I'll outline the necessary kernel configuration.

The basic kernel configuration that I mentioned a long time ago still holds. Basically, you need to have the following options built into your kernel: CONFIG_DM_CRYPT, CONFIG_CRYPTO_CBC, CONFIG_CRYPTO_SHA256, and CONFIG_CRYPTO_AES. Most of those will be turned on when you enable:

Device Drivers ->
  Multiple devices driver support (RAID and LVM) ->
    Device mapper support ->
      Crypt target support

However, the SHA256 support will not be. It can be found at:

Cryptographic API ->
  SHA224 and SHA256 digest algorithm

On the note of kernel configuation: for this process, you will need to do a fair amount of work from within another linux environment (most likely a LiveCD). For Gentoo, the most recent CD image I've found that has all the necessary configuration is the 2006.1 version... As I recall, some of the intermediate minimal CDs, at least, didn't possess cryptsetup at all. And the most recent weekly build I tried, while it did have lvm and cryptsetup installed, didn't have CONFIG_CRYPTO_SHA256 either built in, or as a module.

Probably the best bet is an Ubuntu 8.10 Alternative CD. You'll have to either boot in recovery mode, or go through a bit of the installation procedure, as it doesn't initially have cryptsetup available. But, once it's detected the CD and loaded the modules from it, you can just switch to another virtual console and do things from there.

Next time, I'll outline creating the disk partitions.

by Mike Kelly at December 19, 2014 08:15 AM

Pioto.org is Moving

All of pioto.org is moving to a new server. To start things off, I’m locking my blog read-only. If you want to keep track of all this, Paludis ticket #582 has the details.

by Mike Kelly at December 19, 2014 08:14 AM

Disk encryption w/ dm-crypt (LUKS) and lvm2, part 3

Last time I kinda cheated and gave pretty much a redux of an earlier post. This one will hopefully have some more substance to it.

The partitioning scheme I'm currently using is like this:

/dev/sda1 - /boot (ext2)
/dev/sda2 - LUKS encrypted lvm2 physical volume

The /boot partition is created like any normal ext2 partition.

The sda2 partition is created like so:

cryptsetup luksFormat /dev/sda2

This usually is sufficient to provide decent encryption, but it is worth checking the documentation for cryptsetup to look for further options -- in particular, the option to use a keyfile.

Once we formatted this partition, we'll need to open it, so that we can then add our lvm pv to it:

cryptsetup luksOpen /dev/sda2 sda2_crypt

We'll now have a new device available as /dev/mapper/sda2_crypt. This can be treated just like any other block device -- we could just format it as a regular ext3 partition, but then we can't really ever resize it. So, we're going to make a LVM2 partition:

pvcreate /dev/mapper/sda2_crypt

Now, we create a volume group. I choose 'Exherbo' as the name, but you can really just use whatever (often people just use 'vg').

vgcreate Exherbo /dev/mapper/sda2_crypt

Now, we just need to make our partitions:

lvcreate -L 1G -n swap Exherbo
lvcreate -n root Exherbo
vgscan
vgchange -a y

This creates a 1G swap partition, and uses the rest of the space for our root (/) partition. Again, see the documentation for lvm2 for more options.

Finally, we need to format those partitions:

mkswap /dev/mapper/Exherbo-swap
mke2fs -T ext3 /dev/mapper/Exherbo-root

Next time, I'll go over how to boot this system.

by Mike Kelly at December 19, 2014 08:13 AM

My random old scripts moved to git

So, I had a few random old scripts lying around in SVN. I've migrated them to git now. Along with my other repos, they're browseable at http://git.pioto.org/

Things of interest might be:

  • rbtpb - A replacement for tpb which is hopefully more robust.
  • rubeak - A tool for handling multimedia keyboard keys, and some IR remotes.

Update: fixed links.

by Mike Kelly at December 19, 2014 08:11 AM

Encrypting (almost) your entire hard drive with dm-crypt (LUKS) and lvm2, Part 1

Introduction

About five months ago, I wrote about how to convert an existing Linux install from using regular partitioning to encrypted volumes (in particular, an encrypted /home with an unencrypted /). That sort of setup is relatively simple, once you have all the partitioning done. There is no need for any special early userland stuff (an initramfs image). However, that approach only provides a relatively minimal level of security for your data -- someone could still root your system.

For those who are a little more paranoid (especially in light of some recent news), the next level of security for your data is to encrypt everything except your /boot partition.

Going to this level, you're going to be repartitioning pretty much your entire hard disk, so you might be best off just backing up everything (you should do this in any case), and reinstalling your system.

Some recent Linux installers make this sort of setup relatively pain-free. For example, Ubuntu 8.04's Alternative install disk gives the option of setting up an encrypted LVM volume to install the system on during its guided partitioning wizard. This is a rather easy way have your laptop's data securely encrypted quickly. However, with this setup, I wasn't able to get suspend-to-disk support to function properly (though I'm sure it could be done with a little extra effort, I don't know if most Ubuntu users would be willing to do so).

However, this guide is focused on the crowd of people who use distros that do not make this easy. For myself, I'm installing Exherbo during this guide, but the instructions should be almost exactly the same for Gentoo, or most any other distro.

Partitioning Overview

For this first step, you will need to create two standard disk partitions. The first should be only 32M or so in size -- this will be our /boot partition, and should probably be ext2. The second will be the rest of the space you wish to devote to this Linux install (in my case, 10G).

The final layout of everything is going to be like this:


/dev/hda1 - /boot
/dev/hda2 - dm-crypt encrypted volume, containing one lvm2
  physical volume

/dev/mapper/hda2_crypt - what we get when we run cryptsetup luksOpen
  on hda2, contains one lvm physical volume, containing the volume
  group "vg"

/dev/mapper/vg-swap - our swap partition
/dev/mapper/vg-root - our root partition

With this layout, all our data that can be encrypted / lvm-ized is. And we only need to enter our disk decryption key once to get to all of it.

Next Time...

In my next few posts, I'll go into more details about how to set this partition scheme up, how to configure your kernel, and how to create the necessary initramfs image to boot from an encrypted / partition.

by Mike Kelly at December 19, 2014 08:07 AM

Disk encryption w/ dm-crypt (LUKS) and lvm2, part 4

Previously I described how to partition your drive using LVM2 and dm-crypt. This time, I'm going to go over how to boot this system.

First off, you're going to want to have your livecd handy, because it's likely something won't quite be right the first time around. Also, you'll want to make sure your kernel is built with support for initramfs. This requires the BLK_DEV_INITRD configure option, named "Initial RAM filesystem and RAM disk (initramfs/initrd) support" in the "General setup" menu. You'll then need to specify the location of a source file for the initramfs.

Probably the easiest thing to do is to grab my current initramfs package and tweak it to suit your needs. You'll at the least need to change some paths in the config.txt and init files. But, it should serve as a good starting point. When you're done, put the path to the config.txt file in the "Initramfs source file(s)" (CONFIG_INITRAMFS_SOURCE) setting in the kernel.

Now, rebuild and reinstall your kernel, reboot, and pray.

I hope this will help people improve their laptop's security. Feel free to post any questions you have in the comments. Good luck!

by Mike Kelly at December 19, 2014 08:05 AM

Migrating from Typo to Movable Type

I migrated my blog from Typo to Movable Type a while ago. I wrote a little script to do it, but I've only just now gotten around to cleaning it up enough so that it's suitable for general use.

It's available now from my git repo, and on CPAN

As always, "patches welcome".

by Mike Kelly at December 19, 2014 08:03 AM

Exherbo: Myths and Facts

So, some people seem to have gotten all in a tizzy about Exherbo. While I don't personally think the wording on the front page is necessarily the best, here's the deal:

  • We don't hate you. We just know we don't quite have something ready for general use. Rather than deal with many users wanting to try out something that most likely will not work for them, we have attempted to dissuade people from trying Exherbo until we think it's ready for them to.
    • "Then why announce it?" Because Bryan is going to discuss it at an upcoming conference, so we decided we should have some sort of web page up. We didn't put it up on Slashdot, though.
  • This isn't Ciaran's brainchild. It's Bryan Østergaard's (aka kloeri). Yes, Ciaran is involved in the project, along with a number of other former Gentoo developers, but he isn't the "lead" (though I don't think we really formal roles at this point).
  • "Why don't you use...?" We've already looked at many existing projects to fill some of the spots we've decided to fill ourselves instead. For example, we took a look at upstart, Gentoo's baselayout 1.x, openrc, etc. However, none of them seemed to do quite what we wanted. That's why we're working on projects like genesis, why we're writing our package tree from scratch, and using our own package format.

So, I hope this helps to clarify things for some people who still seem to be confused as to what Exherbo is all about.

Update: fix links.

by Mike Kelly at December 19, 2014 08:01 AM

Random Perl Hacking

My day job mostly involves Perl, so I've been using it more for my random tasks at home. I've now put a few of them up on CPAN:

  • Unix::Uptime - Determine the current uptime, in seconds, and load averages, across different *NIX architectures.
  • Remind::Client - class for working with remind's daemon mode

I also have a few other scripts I've been messing around with, for doing some reporting and such:

by Mike Kelly at December 19, 2014 07:57 AM

October 01, 2014

Ciaran McCreesh

Paludis 2.2.0 Released

Paludis 2.2.0 has been released:

  • Bug fixes.
  • Compilation fixes for Clang.
  • Added ‘cave resolve –chroot-path’.
  • Removed the “breaks Portage” feature.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at October 01, 2014 06:05 PM

July 11, 2014

Wulf C. Krueger

Quick information: Jenkins’ build scripts are in git and Gerrit

Just a small update today: You can find my build bash scripts for Jenkins in git and Gerrit now.

 

Gerrit:

git clone https://galileo.mailstation.de/gerrit/jenkins-build

cgit:

https://galileo.mailstation.de/cgit/cgit.cgi/jenkins-build.git/

Plain old git:

git://galileo.mailstation.de/jenkins-build.git
ssh://git@galileo.mailstation.de/jenkins-build.git

 

Please submit patches via Gerrit.

by Wulf C. Krueger at July 11, 2014 05:42 PM

June 27, 2014

Wulf C. Krueger

Server update: Gerrit, Jenkins & friends (some downtime today)

As some of you will have noticed, my server galileo.mailstation.de has had some performance issues lately. Testing patches with Jenkins could take a long time, building stages was taking up to 20 hours (!) instead of the normal two and Gerrit itself could be slow at times as well.

This was due to aging hardware (that server was assembled in 2010), one horribly performing hard disk and constant over-heating of the machine. I’ve changed a few things over the last few days and performance is much better now but still not to my satisfaction.

Today, I’ve finally had enough of squeezing performance out of rotting hardware and simply ordered a new server. Functionally, it will be identical to good old galileo but on beefier hardware, especially with much more RAM (48 GB instead of 12 GB) which is essential for my uses.

While I’m writing this, I’m copying over the entire galileo to the new server which will hopefully be finished in a few hours from now. Once that’s done, I’m going to

  • shut down all non-essential services on galileo (that includes Gerrit, Jenkins, the bots and lots of other stuff),
  • re-sync the data to the new server,
  • change the DNS records,
  • fire up all current services on the new server,
  • rejoice!

(N. B.: Should you think I’ve forgotten something important here, please comment while you still can. :-) )

This update will, thus, cause some downtime (there was some earlier today already when I was preparing the migration). So don’t be alarmed if all services (including my IRC bouncer :-) ) are gone for a while – we’ll be back!

Ideally, you’ll only even read this post when all is over. :-)

by Wulf C. Krueger at June 27, 2014 04:09 PM

May 07, 2014

Wulf C. Krueger

Stages – some changes

As most of you know from my earlier stage building post, our stages for amd64 and x86 are being built automatically using Jenkins. And that won’t change.

 

Recently, there has been a discussion about adding Emacs to the stages in addition to vim. The reaction was overwhelmingly negative; even more so than I had expected.

 

Since…

 

  • I’m the one who spends his time and actual money on building stages, deploying them to exherbo.org, dealing with fall-out from changes, etc.,
  • there’s no real argument against adding Emacs but “it’s not POSIX!” and “stages should be minimal!”, “only having Vim is a nice filter against the kind of user we don’t really want anyway”, “use the editor outside the stage”, etc.
  • people are told to use e4r, which stands for “editor for retards” and is neither Emacs nor vim and, thus, doesn’t fix the problem,

 

… this is what I’ve changed effective by May, 7th 2014

 

  • I’ve added Emacs to the stages I build unilaterally (the first stage with Emacs included will be built on May, 8th 2014),
  • I’m not going to change the stages set because that would influence any stages not built by me,
  • I’ve stopped deploying the stages I build to exherbo.org (the last stage I deployed there is of May, 7th 2014),
  • The stages I build will always be located at https://galileo.mailstation.de/stages/ (where they’ve been since I started building them),
  • I’ve added the link to the stages on my server to the install guide as an alternative.

 

In consequence…

 

  • if it is that big a deal that Emacs will be included in my stages, someone else will have to build official stages manually,
  • if it’s not that big a deal, our core devs can say so on our mailinglist and I’ll gladly revert things to how they were – just with Emacs in the stages set.

 

by Wulf C. Krueger at May 07, 2014 09:12 PM

April 21, 2014

Wulf C. Krueger

Exherbo’s Gerrit for 3rd party repositories

Exherbo’s Gerrit has left its infancy and, thus, I can now add 3rd party repositories to our Gerrit installation. Please just let me know if you’d like that.

  • Requirements:
    • Your repository must use git.
    • You must have an account in Gerrit.
    • You must be willing to add a Gerrit user (github: Gerrit-Exherbo) to your repository as a contributor.  Here’s the public key. (You don’t need the public key for github; if you’re unsure, you most likely don’t need it.)
    • Your repository should be hosted on one of the big git hosting providers, e. g. github (preferred) or gitorious. Ask me if your repository is hosted elsewhere; I do make exceptions.
    • Please let me know the push URI for your repository.

Once I’ve set you up, you can immediately work on Gerrit patches for your repository. You are, of course, its sole owner and fully responsible for it.

By default, Exherbo’s core devs (but nobody else unless you explicitly ask me to add someone) will be able to +2 Gerrit changes for your repository, too. This is meant to potentially help you keep your repository up to date (e. g. when mass changes occur). This is entirely optional, though, and you can choose to opt-out at any time if you don’t like it; you only need to let me know.

by Wulf C. Krueger at April 21, 2014 11:28 AM

April 16, 2014

Wulf C. Krueger

Miscellaneous Updates to Gerrit, Jenkins & friends

Over the last few weeks, I’ve made a few changes to Exherbo’s Gerrit and Jenkins installation:

  • Build artifacts are stored in Jenkins:

    If a build is unsuccessful, the Paludis build log, config.log (if it exists) and the cave-resolve command used are stored. Since build artifacts are associated with a project (i. e. the repository) and not individual builds, the files have the build number prepended in their file name:
    77_build.log
    77_cave-resolve.txt
    77_config.log

    If a build is successful, only the cave-resolve command and the detected dependencies are archived:

    78_cave-resolve.txt
    78_dependencies.txt

    This change is effective immediately for all exheres repositories in Jenkins. If you have further suggestions of files to archive, please let me know.

 

  • Due to the recent OpenSSL Heartbleed bug issue, I’ve re-issued the SSL certificates on my machines on April, 11th 2014. If you have a password login on galileo, now is the time to change it. For galileo.mailstation.de, the host key fingerprints are as follows:

1024 a8:8c:7d:87:3d:a6:61:78:8d:59:f5:52:d7:b1:3c:34 (DSA)
256 f1:08:b0:12:66:1c:72:af:2d:d8:c7:15:ca:13:f6:f2 (ECDSA)
256 68:1c:27:e2:8e:b5:42:62:98:8a:f3:04:45:c1:60:f9 (ED25519)
2048 37:38:6e:81:4a:53:24:4d:b0:fb:c7:3e:f0:1d:63:8c (RSA1)
2048 06:57:ff:b7:e6:6f:c8:31:76:c8:9a:7c:37:d7:f5:47 (RSA)

The web server’s certifacte has the following fingerprints:
  • SHA-256 Fingerprint:
    85 3D 47 8B A5 44 76 A0 09 96 9F 15 4A 9A F8 C5 1C 95 D1 1D 92 4E 78 06 0D F6 E5 7B 1B C5 B2 07
  • SHA-1 Fingerprint:
    0D E8 77 4F 74 67 AB 61 12 97 A5 57 84 1F B4 51 C1 1D D4 19

 

  • Gerrit was updated to version 2.8.4. There are quite a few bug fixes in the release notes but probably most important for those of you who experienced issues with the side-by-side diff view in the new change screen are the fixes they applied to it.

 

There’s more to come but that’s going into another post. :-)

by Wulf C. Krueger at April 16, 2014 01:18 PM

March 05, 2014

Wulf C. Krueger

Re-testing patches in Gerrit with Jenkins

A recent request concerned the possibility to re-test patches patches in Gerrit with Jenkins. I’ve now added a very simple switch for that:

In any given given change (but your own!), you can add a comment with “+1 Retest” set as a “verdict”. On the old change screen (really, change to the new one, it’s much nicer), it looks like this:

Retest: Old change screen

 

On the new change screen, it looks like this:

Retest: New change screen

It’s really, truly easy. You can even do it multiple time – just uncheck the “Retest” checkbox (new screen) or set “0 Retest” (old screen) first and then set it again.

This works for any change as long as you are a registered user – any change but your own. Unfortunately, the Jenkins’ Gerrit-Trigger plugin simply ignores the “CommentAdded” event completely for ones own changes. If you want those re-tested, just amend your commit (no need to actually change anything; the commit timestamp will be updated) and Jenkins will see the patch’s new revision and re-run the test.

 

On a side note, I’d like to apologise for the instability for about 1,5 days earlier this week. There were some really nasty hardware/software issue that I had to sort out. This is done now, though, and things are running smoothly again.

 

by Wulf C. Krueger at March 05, 2014 06:13 PM

February 27, 2014

Wulf C. Krueger

Automated stage building with Jenkins

For quite some time now, I’ve been working on the automatic creation of Exherbo stages for AMD64 (x86_64) and X86 using Jenkins.

Till now, Exherbo’s stages were created manually by one of us Exherbo core developers and usually basically “on-demand” or when they were major changes. This finally changed yesterday.

Using the jobs stage_amd64 and stage_x86 respectively, the stages…

  • are built using a modified stage building script – each stage is build from scratch. The latest stage gets unpacked and used to build a new one. I call this: Implicit pro-active quality assurance. No pbins are used in the entire process. Everything is fresh and new, just for you.
  • the sources are kept right next to the stages at https://galileo.mailstation.de/stages/sources. You can see right there what sources were used.
  • the XZ archive is added to the job (the most recent ten stage archives are kept on their respective job). Like this, you can always check the exact build log for the stage you want and rest assured both are right there at your fingertips.
  • next, the successfully built stage is deployed to https://galileo.mailstation.de/stages/. exherbo.org is undergoing maintenance but you really want your Exherbo? Download a stage from this alternative location, sync your repositories from Gerrit and you’re unstoppable!
  • and finally automatically transferred to our traditional http://dev.exherbo.org/stages/ where some “extra magic” is performed by Jenkins that creates the “current” symlinks, updates the checksum files, etc.

And this happens every single day. The entire process is completely scalable as well – once the cross stuff is production-ready, I’m going to build ARM stages as well and it will be done by simply copying a Jenkins job and changing a few lines. A milestone for Exherbo.

We just made major changes? Wait a few hours, get them in your stage for your new Exherbo installation.
You somehow got a broken stage? Use an older one, compare them, go nuts with them. There are always at least 10 stages per architecture to choose from.
And if a stage fails to build? Well, the next day it will be fixed because we’re watching over the entire process.

Isn’t this incredibly awesome?

And you can even play a round of Bullshit Bingo using this very post! ;-)

 

by Wulf C. Krueger at February 27, 2014 08:58 PM

February 23, 2014

Bryan Østergaard

So I was dox'ed yesterday

and nobody gives a fuck.

Here's the associated spam:
14:53 < ~dd0sb0ss> rip
14:53 < ~dd0sb0ss> PARTY AT Vølundsgade 31, 3. th. 2200 København N
14:53 < ~zsasz> ur unicode is broken dd0sb0ss
14:53 < ~dd0sb0ss> fuq
14:54 < ~dd0sb0ss> THE OFFICIAL FREENODE PARTYLINE IS REACHABLE AT +4533137886
14:54 -!- dd0sb0ss was kicked from #freenode by kloeri_ [dd0sb0ss]

Ignoring the broken unicode that's actually the correct information. Well done on finding this information that has been publically available (by my own choice) for several years.

It's never been hard to find me and that's not changing in the future just because of some silly kids either. Unlike these kids I'm actually proud of what I do and I'm more than happy to stand by my actions with my real name and even address widely available.

And for all those sensible people out there just shaking your heads at this sillyness - you're welcome to visit, especially if you are interested in open source software or need a consultant on some project :) I'd suggest contacting me by email first though.

PS. Thanks to GNAA for this obvious advertising opportunity.

February 23, 2014 08:49 PM

January 03, 2014

Wulf C. Krueger

Jenkins: Build-testing for every single commit

As of yesterday, I’ve drastically increased the number of testing machines in Jenkins (from two to 21!). This enables me to poll for changes in git every five minutes and automatically start a testing run for every single commit – regardless of it entering via Gerrit or not. (Note: This is in addition to the Gerrit trigger I’ve been using from day one on, not replacing it.)

Here’s an example from today:

https://galileo.mailstation.de/jenkins/job/arbor/67/

Apart from looking at Jenkins directly, you can join the #exherbo-bots channel where the jenkins-exherbo bot announces all test results. Here’s an example for that:

[03.01.2014 13:42:59] <irker657> Exherbo: pipping arbor:master * 76ec9309669d / packages/sys-apps/grep/grep-2.15.exheres-0 packages/sys-apps/grep/grep-2.16.exheres-0: grep: Bump to 2.16 http://tinyurl.com/pyfhbql
[03.01.2014 13:46:50] <jenkins-exherbo> Project arbor build #67:SUCCESS in 1 min 5 sec: https://galileo.mailstation.de/jenkins/job/arbor/67/

I hope you’ll find this useful and will actually look at the results since it will find out if you missed a dependency. And it potentially shows you automagic dependencies.

 

by Wulf C. Krueger at January 03, 2014 04:29 PM

Version bump to systemd-43 / Move to /usr

(This is the same as the news item but I want this to get maximum exposure.)

Read ALL of this, it’s important to everyone using systemd.

Up to systemd[=42] we installed boot-critical components to / and others to /usr. This split was causing issues with respect to tmpfiles, intrinsic dependencies and dependencies on stuff on /usr.

systemd[=43] finally removes this split and installs everything but udev and pam stuff to /usr.

This won’t matter much to you if you don’t have /usr split from / (it should not be split; cf. http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken).

Even if you don’t have /usr != /, you need to update all packages that install to /${LIBDIR}/systemd/system because that got moved, too, of course. I’ve rev-bumped all packages, that install their own custom systemd units but even after you’ve updated those, you’ll still have some in /${LIBDIR}/systemd/system. Find out which package they belong to (use cave owner) and re-install them.

Should you forget to do so, you might end up in systemd’s emergency mode. If that happens, don’t panic. Get your network connection up and continue updating/re-installing. You’ll live, I promise.

There might be orphaned systemd units left behind. Check those on your own and decide if you need to move them to /etc/systemd/system. If you do, don’t forget to systemctl disable and then enable them.

You’ll also have some broken symlinks in /etc/systemd/system pointing to /${LIBDIR}/systemd/system. To fix those, all you have to do is disable and re-enable the respective unit. Here’s how to do it quickly and easily:

for link in $(find -L /etc/systemd/system -type l); do
systemctl disable $(basename ${link});
systemctl enable $(basename ${link});
done

Final sanity checks:

1. Is /${LIBDIR/systemd gone? If so, carry on; if not, you missed a step. Go back and find out which one.

2. No broken symlinks in /etc/systemd/system anymore? (“find -L /etc/systemd/system -type l” doesn’t output anything) If so, carry on. Otherwise, you missed a step. Go back and find out which one.

If you do NOT have /usr separated from /, you’re done now and it should be safe to reboot if you so desire.

If you do have /usr separated from /, you’ll have to use an initramfs (preferrably created by dracut) for booting from systemd[=43] onwards.

The first step to using an initramfs is enabling CONFIG_BLK_DEV_INITRD in your kernel, recompiling and installing it. If you want to switch from a custom initramfs to dracut, don’t forget to empty CONFIG_INITRAMFS_SOURCE in your kernel configuration either if you have been using it before.

If you want to use dracut (sys-boot/dracut[>=14]), install it and add

add_dracutmodules+=”98usrmount”

to /etc/dracut.conf. If you have some weird configuration, you might need to add further dracut or kernel modules. In general, though, dracut is going to pick up everything you’ll need to boot.

Now run dracut to create your shiny new initramfs:

dracut -H <initramfs filename incl. path> <kernel version>

e. g.

dracut -H /boot/init-3.2.5.gz 3.2.5-00001-gf74dd96

-H (or –hostonly) tells dracut to build an initramfs for the machine it’s running on. Leaving it out should create a HUGE generic initramfs that should bascially be able to boot everything. In reality, leaving -H out usually builds something that doesn’t boot anything.

Next, update grub’s config so that it includes a root= parameter for the kernel command line and your new initramfs, e. g.:

(for grub-0.9x’s menu.lst)
title Exherbo Linux
root (hd0,1)
kernel /kernel-3.2.5-00001-gf74dd96 root=/dev/primary/uselv
initrd /init-3.2.5.gz

or

(for grub-1.9x’s grub.cfg)
menuentry “Exherbo Linux” {
set root=(hd0,1)
linux /kernel-3.2.5-00001-gf74dd96 root=/dev/primary/uselv
initrd /init-3.2.5.gz
}

Do NOT forget the root= parameter. It’s essential.

(Of course, you need to adjust paths and filenames to your setup but if I need to tell you that, you shouldn’t be using Exherbo in the first place.)

If you’re using a custom initramfs, you must make sure that you mount /usr as early as possible but definitely before systemd (/sbin/init) starts. If you’re rolling your own initramfs, you should know how to accomplish that.

After you’ve updated your grub configuration, systemd is updated and your kernel is ready, too, say a little prayer ;-) and reboot.

Best regards, Wulf

by Wulf Krueger at January 03, 2014 12:56 PM

Samba has no maintainer on Exherbo any more

After having worked with Samba for almost 20 years, I'm giving up now.

I have submitted patches upstream when Samba (and I :) ) was young,
I've proof-read books on Samba and NTLM but where they're going, I
can't follow them any more.

- Samba 4.1.0 doesn't even build for me any more and I'm too
frustrated to figure it out.

- In Samba 4.1.0, SWAT (the configuration web interface) seems to have
been removed. I might be missing something but if I'm not, that sucks.

- Samba's "new" crappy build system WAF is just horrible and I simply
don't understand it. I asked for help (and it was offered) but nothing
was ever done.

- New versions of Samba 4 try to build against already installed
versions in the live filesystem and I don't understand WAF enough to
fix that.

I've just removed myself from BUGS_TO. If you want it, take it but if
you do, do me a favour and do a better job than me and make sure
you're weird enough to understand (and ideally like) WAF.

by Wulf Krueger at January 03, 2014 12:55 PM

Exherbo’s Patch Queue

Today, on May, 5th 2012, our patch queue on Zebrapig the Ugly did the impossible; it achieved re-floration! ;-)

 

[05.05.2012 21:57:36] <Philantrop> !pl

[05.05.2012 21:57:37] [Notice] -zebrapig to #exherbo- 0 patches in queue:

 

by Wulf Krueger at January 03, 2014 12:54 PM

paste.pocoo.org is gone for good. Please re-submit your patches.

paste.pocoo.org is gone for good. Please re-submit your patches.

Here’s the list of affected patches:

[28.04.2012 17:24:28] [Notice] -zebrapig- 13 matching patches in queue:
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/510003/ ::sydbox (submitted by worr 161 days and 17 hours ago): [PATCH] Fixed race condition in sydbox
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/579419/ ::kde (submitted by heirecka_ 17 days and 5 hours ago): [PATCH 1/2] Move stuff from qt-creator-scm to its exlib
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/582592/ ::arbor (submitted by SuperHeron 11 days and 20 hours ago): [PATCH] app-shells/bash-completion[=scm]: /etc/bash_completion.d is
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/582875/ ::x11 (submitted by moben 11 days and 8 hours ago): [PATCH 1/2] mesa multilib: Use multiunpack exparam
[28.04.2012 17:24:30] [Notice] -zebrapig- http://paste.pocoo.org/raw/583000/ ::arbor (submitted by keruspe 11 days and 1 hour ago): [PATCH] llvm: allow gcc 4.7.0
[28.04.2012 17:24:32] [Notice] -zebrapig- http://paste.pocoo.org/raw/584582/ ::mawww (submitted by heirecka 8 days and 3 hours ago): [PATCH] Fix building of espeak
[28.04.2012 17:24:34] [Notice] -zebrapig- http://paste.pocoo.org/raw/585239/ ::arbor (submitted by SuperHeron 7 days and 4 minutes ago): [PATCH] dev-lang/python: Add .pc file into alternatives
[28.04.2012 17:24:36] [Notice] -zebrapig- http://paste.pocoo.org/raw/585373/ ::anderslm (submitted by Philantrop 6 days and 18 hours ago): [PATCH] dev-libs/dotconf: ::anderslm -> ::media
[28.04.2012 17:24:38] [Notice] -zebrapig- http://paste.pocoo.org/raw/586847/ ::kde (submitted by Apetrini 3 days and 13 hours ago): [PATCH] networkmanagement: bump to 0.9.0.1-r1, fix dep
[28.04.2012 17:24:40] [Notice] -zebrapig- http://paste.pocoo.org/raw/588002/ ::ingmar (submitted by nakamuray 1 day and 3 minutes ago): [PATCH 1/3] notmuch: version bump to 0.12
[28.04.2012 17:24:42] [Notice] -zebrapig- http://paste.pocoo.org/raw/588028/ ::arbor (submitted by keruspe 23 hours and 6 minutes ago): [PATCH 1/3] autoconf: bump to 2.69
[28.04.2012 17:24:44] [Notice] -zebrapig- http://paste.pocoo.org/raw/588037/ ::x11 (submitted by keruspe 22 hours and 47 minutes ago): [PATCH] xkeyboard-config-scm: fix build
[28.04.2012 17:24:46] [Notice] -zebrapig- http://paste.pocoo.org/raw/588130/ ::kde (submitted by heirecka_ 19 hours and 56 minutes ago): [PATCH] Version bump to akonadi-1.7.2

by Wulf Krueger at January 03, 2014 12:54 PM

Gerrit Code Review for Exherbo

As an experiment,  I’ve installed a Gerrit Code Review instance on my server for use with Exherbo.

Gerrit is a code review tool and allows for

 

- discussing patches and keeping the results for future reference
- get notified by email about every change (if you want)
- easily work on every official Exherbo repository (more to come later if people are interested)
- contributors to get their repositories added to Gerrit as well (optional)

 

You’ll find an introduction to Gerrit here:

 

 

 

Random thoughts:
- If Gerrit isn’t being used, it will go away. This is an experiment because I think Zebrapig (albeit its undisputed merits) has inherent limitations that can’t be easily fixed.
- Gerrit is not supposed to supersede Zebrapig but to complement it.
- There have been controversial internal discussions about this. Please keep in mind that I don’t mean to take anything away from anyone but to improve Exherbo.

 

Notes about the installation:
- The Gerrit instance fetches and pushes repository updates every 15 minutes. Gerrit now replicates merged changes pretty much immediately. This sometimes/rarely fails on the first attempt for various reason. I’ve implemented a fallback that occurs every 15 minutes.
- You need an OpenID to register. This is mostly for copyright reasons as well and probably won’t change. (I’ve evaluated a lot of other options; they all had in common that they couldn’t be used together with other methods.)
- You MUST use your real name for copyright reasons.
- In the future there might be a mailinglist that gets all notifications from Gerrit. For now, please subscribe/unsubscribe to/from notifications yourself as you see fit.

 

 

 

How to use Gerrit:

 

 

Registration and initial setup: 

 

 

2. In the upper right corner, click “Register”.
3. In the next screen, enter your full name (for copyright reasons, it must be your real name) and choose a user name.
4. Paste your ssh public key into the box at the bottom and click “Add”. If you don’t have one, there’s an explanation about creating one.
5. Click ”Continue”.
6. Click on your full name in the upper right corner (where “Register” was), and choose “Settings”.
7. Enter a git/https user name. You can use the one you chose in step 3.

 

 

Cloning a repository:

 

1. Click “Projects”, “List”, then choose a project.
2. You should see several methods for cloning the project, the easiest way is to choose the ssh method.
3. Clone, e. g. git clone ssh://<user name>@galileo.mailstation.de:29418/alip
4. Install a hook that sets a Change-Id automatically (choose one of the two alternatives):

scp -p -P 29418 <your username>@galileo.mailstation.de:hooks/commit-msg <local path to your repository>/.git/hooks/
curl -o <local path to your repository>/.git/hooks/commit-msg https://galileo.mailstation.de/gerrit/tools/hooks/commit-msg

 

 

Submitting:

 

There are several methods to upload changes. The easiest is to just push:

 

1. Work on your copy of the repository, commit.
2. Push your changes: git push origin HEAD:refs/for/master

 

 

You can use git review for easily setting up your repository clone and submitting patches, too. I haven’t tested it myself, though. It’s quite nice, use it!

 

 

by Wulf Krueger at January 03, 2014 12:54 PM

News about Gerrit, Jenkins & friends

Here are a few things I’ve updated on Gerrit, Jenkins and associated tools:

  1. Gerrit
    • The Gerrit bot, gerritwk23, has now support for !pl (and pl in a query). It’s just like zebrapig’s !pl.
    • I’ve updated Gerrit in mid-Decembre. Since then, you can switch to a newly designed “Change View” which you’ll find under your account’s settings in the “Change View” option. There’s also an associated “Diff View” option to set your preferred diff style if you switch to the new Change View.

2. Jenkins

    • In its build logs, you’ll now find the mounts, the cave resolve command and the (likely) dependencies gathered from the installed package. Dependency information might not be 100% accurate so please take it with a grain of salt but it’s usually a good indicator.
      Look out for “**************************************************************” to find that information.

 

If you have any ideas about what else to improve, please let me know.

by Wulf C. Krueger at January 03, 2014 12:54 PM

Another good reason to use Gerrit: Jenkins is at your service

If it’s not yet good enough for you that using Gerrit

  • is even easier and faster than using zebrapig (you just push your change and you’re done! And if you use git review it’s getting even easier.),
  • the review turn-around times are often better when using Gerrit than zebrapig,
  • discussing patches can be done both when you’re on IRC and on Gerrit,

then here’s another good reason to use it: I’ve set up Jenkins for all repositories on Gerrit to build every change in a chroot (including sydbox-1, pinktrace-1 and docs).

For now, all reports only go to me (and anyone else who wants to get an email with the result included) and Jenkins will not report back to Gerrit because the setup is quite fragile yet and I want to be sure it works properly before making it do more.

No idea how to use Gerrit? Just read my earlier posts Gerrit Code Review for Exherbo and Gerrit for Core-Devs. Of course, you can ask me, too. :-)

 

by Wulf C. Krueger at January 03, 2014 12:54 PM

Gerrit installation updated to the 2.7 release, pesky “internal server error” fixed

I’ve just updated the Gerrit installation to the 2.7 release and fixed the pesky “internal server error” that occurred when entering a user name or similar.

I’ve also updated my posts on Gerrit and the FAQ-like post for core devs:

Experiment: Gerrit Code Review for Exherbo

Gerrit for Core-Devs

 

 

by Wulf Krueger at January 03, 2014 12:54 PM

Gerrit for Core-Devs

There have been a few questions and potential misunderstandings I’m going to try to address here. I’ll update this post if new stuff comes up.

  • Getting the foo Or: How do I become a Core-Dev on Gerrit?
    Simple: You register with your OpenID then you ask any other core dev to add you to the group. At least Bo “zlin” Ørsted Andresen and I know how to do it and every member has the necessary privileges.
  • Reviewing Or: +1+1 != +2
    Every registered user can comment and/or +1 a change. This is an indication said user has reviewed the patch and, ideally, tested it. It’s basically only an opinion, though.
    Only Core-Devs can +2 a change. This means they’ve reviewed and tested that change and are approving it. The change then will get merged and pushed.
    It’s important to remember, though, that +1′s do NOT add up. You can +1 a change a hundred times but it will still need one bold man (or woman) to +2 it.
    Important as well, use the “Publish and Submit” button, not the “Submit” button if you want to get a change merged.
  • What about testing (or the lack of)?
    Nothing has changed compared to Zebrapig. Everyone who +2′s a change at least (ideally, +1 would indicate you tested the thing, too!) is expected to have actually tested it. If you +2 it but didn’t test it, we’re going to slowly roast you over a scented candle. 
  • What’s the easiest way to test a patch?
    Personally, I look at the patch, at the “Downloads” line, I click on “Patch” and then click on the small clipboard icon next to the git fetch comand. That adds said line to your clipboard. Next, I cd into the respective repository, paste the line we just copied and append “| git am”. That’s it, patch applied, now test it!
  • Merging & pushing (no, not like that, you pervert!)
    Gerrit now pushes merged changes directly to our repositories. This means, once you +2 a change (cf. first point), you push it.
  • Command line tricks or How do I…
    … most easily review a change?

    git review -d -t <change number, e. g. 202>

    … merge a boat-load of patches I reviewed and tested at once?

    On your branch with the changes applied: ssh -p 29418 <username>@galileo.mailstation.de gerrit review –code-review +2 –submit $(git rev-list gerrit/master..HEAD)

    … query for a specific change?

    ssh -p 29418 <username>@galileo.mailstation.de — gerrit query –comments change:212

    …  get a list of all open changes?

    ssh -p 29418 <username>@galileo.mailstation.de — gerrit query status:open (add a “project” parameter if you want only changes for a certain repository, e. g. “project:arbor”)

    … add a comment from the command line?

    ssh -p 29418 <username>@galileo.mailstation.de — gerrit review -m “\”At the very least this commit message should explain why we have to put PWD in PYTHONPATH which can’t be quoted properly… But other than that, seems sensible at least for now.\”” $changeid

by Wulf Krueger at January 03, 2014 12:54 PM

October 13, 2013

Ciaran McCreesh

September 24, 2013

Ali Polatel

A Study in Sydbox

Due to the fact that sydbox is a low level tool which inspects system calls, debugging its bugs become cumbersome at times. GDB and Valgrind are two valuable tools which comes to rescue.

I hit this bug when I was investigating Exherbo bug 369. I wrote a small C program to reproduce the problem:

    #include <errno.h>
    #include <string.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <fcntl.h>
    #include <elf.h>
    #include <sys/auxv.h>
    #include <sys/types.h>

    int main(void)
    {
        pid_t pid;
        int pfd[2];
        unsigned long val;
        char buf[1024];
        int auxfd;

        val = getauxval(AT_SECURE);
        fprintf(stderr, "getauxval(%lu) = %lu (errno:%d %s)\n",
            AT_SECURE, val, errno, strerror(errno));

        pipe(pfd);
        pid = fork();
        if (pid == 0) {
            /* 23 is AT_SECURE as defined in elf.h */
            char *const argv[] = {"sh", "-c", "od -t u8 | awk '{if ($2 == 23) print }'", NULL};
            close(pfd[1]);
            dup2(pfd[0], STDIN_FILENO);
            execvp(argv[0], argv);
        } else {
            close(pfd[0]);
            auxfd = open("/proc/self/auxv", O_RDONLY);
            while (read(auxfd, buf, 1024) > 0)
                write(pfd[1], buf, 1024);
            close(pfd[1]);
        }
    }
    

I compiled this small program with gcc and when I run it under sydbox-1 I witnessed an interesting output:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ./sydbox ./a.out
getauxval(23) = 0 (errno:0 Success)
sydbox@1379972151: bash[26306.0:26305] sys:4|stat| PANIC_KILL

Note there is not a prompt at the end. sydbox-1 hung right after logging PANIC_KILL. Before firing up a debugger and start to debug, let’s gather as much information as possible by checking whether verbose logging will tell us something:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ./sydbox -m log/console_level:511 ./a.out
...
sydbox@1379972294: [wait(-1, 0x857f) = 28848] WIFSTOPPED,sig=133|(null)|
sydbox@1379972294: [wait(-1, 0x857f) = 28848] WIFSTOPPED,sig=133|(null)|
sydbox@1379972294: [wait(-1, 0x857f) = 28848] WIFSTOPPED,sig=133|(null)|
sydbox@1379972294: bash[28848.0:28847] sys:4|stat| entering system call
sydbox@1379972294: bash[28848.0:28847] sys:4|stat| PANIC_KILL
sydbox@1379972294: bash[28848.0:28847] sys:4|stat| trace_kill(sig:9) failed (errno:3|ESRCH| No such process)
sydbox@1379972294: process 28848 ignored

After a couple of wait(2) loops the stat(2) system call handler - which takes magic commands as input paniced for some reason and called the function panic() which decided to kill the traced process.

So far so good. Although this looks unrelated to the bug at hand, it is still a good idea to fix it when you have some free time. Let’s fire up the debugger and try to do a reverse debug. I use cgdb which provides a nice curses frontend to gdb.

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % libtool --mode=execute cgdb --args ./sydbox -m log/console_level:511 ./a.out
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/alip/src/sydbox/sydbox-1/src/.libs/lt-sydbox...done.
(gdb)

First let’s break on main(), run the program and when the breakpoint is hit set another breakpoint on sys_stat (the stat(2) system call handler function) and start [recording][recording] the program instructions and continue.

(gdb) break main
Breakpoint 1 at 0x419d98: file sydbox.c, line 1255.
(gdb) run
Starting program: /home/alip/src/sydbox/sydbox-1/src/.libs/lt-sydbox -m log/console_level:511 ./a.out
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Breakpoint 1, main (argc=4, argv=0x7fffffffd428) at sydbox.c:1255
(gdb) record
(gdb) break sys_stat
Breakpoint 2 at 0x411d58: file syscall-special.c, line 150.
(gdb) cont
Continuing.
Do you want to auto delete previous execution log entries when record/replay buffer becomes full (record full stop-at-limit)?([y] or n)

This takes some time. When the record/replay buffer is full, gdb kindly asks you whether you want to continue execution and auto-delete previous log entries or stop instantly and investigate further on. We’re not interested in the previous log entries so let’s just hit [enter] and continue.

Process record and replay target doesn't support syscall number -1
Process record: failed to record execution log.

[process 8201] #1 stopped.

This is a weird message by gdb which fortunately I have seen before. sydbox-1 makes use of some rather new system calls which gdb does not support. The newest of those are process_vm_readv and process_vm_writev which were added to Linux as of kernel version 3.2. I’ll add a small one-time tweak to the auto-generated pinktrace/system.h file telling sydbox-1 that these system calls are not supported by the system and let it use the good old ptrace(2) way of reading one long at a time:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % cd ../pinktrace
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % sed -i -e '/^#define PINK_HAVE_PROCESS_VM_\(READ\|WRITE\)V/s/1/0/' system.h
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % grep PINK_HAVE_PROCESS system.h
#define PINK_HAVE_PROCESS_VM_READV      0
#define PINK_HAVE_PROCESS_VM_WRITEV     0
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % make clean && make -j

Now let’s return to src/ and rebuild sydbox:

alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % cd ../src
alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % make clean && make -j

Let’s re-run sydbox to make sure the bug is still there:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ./sydbox ./a.out
getauxval(23) = 0 (errno:0 Success)
0000340                   23                    0

This is where my luck kicks in! The bug is not there anymore. Now we know the problem is actually in pinktrace, the underlying library providing thin wrappers around the ptrace(2) system call. We have also narrowed the problem down to one of process_vm_readv and process_vm_writev functions. Now let’s go back to turn the #defines on and retry with gdb:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % cd ../pinktrace
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % sed -i -e '/^#define PINK_HAVE_PROCESS_VM_\(READ\|WRITE\)V/s/0/1/' system.h
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % grep PINK_HAVE_PROCESS system.h
#define PINK_HAVE_PROCESS_VM_READV      1
#define PINK_HAVE_PROCESS_VM_WRITEV     1
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % make clean && make -j
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % cd ../src
alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % make clean && make -j

Now we will start recording only after we enter the sys_stat() function:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % libtool --mode=execute cgdb --args ./sydbox -m log/console_level:511 ./a.out
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/alip/src/sydbox/sydbox-1/src/.libs/lt-sydbox...done.
(gdb) break sys_stat
Breakpoint 1 at 0x411d58: file syscall-special.c, line 150.
(gdb) run
...
sydbox@1379974050: [wait(-1, 0x857f) = 31387] WIFSTOPPED,sig=133|(null)|
sydbox@1379974050: [wait(-1, 0x857f) = 31387] WIFSTOPPED,sig=133|(null)|
sydbox@1379974050: bash[31387.0:31386] sys:4|stat| entering system call 

Breakpoint 1, sys_stat (current=0x62fa00) at syscall-special.c:150
(gdb) record
(gdb) cont
Continuing.
Process record and replay target doesn't support syscall number -1
Process record: failed to record execution log.

[process 31382] #1 stopped.
0x00007ffff78fa048 in process_vm_readv () from /usr/lib/libc.so.6

Gdb kindly stopped where the bug is actually located. Let’s stop recording and single-step to see what error this function returns.

(gdb) record stop
Process record is stopped and all execution logs are deleted.
(gdb) n
Single stepping until exit from function process_vm_readv, which has no line number information.
_pink_process_vm_readv (pid=31387, local_iov=0x7fffffffbe10, liovcnt=1, remote_iov=0x7fffffffbe00, riovcnt=1, flags=0) at vm.c:199
(gdb) n
(gdb) p r
$1 = -1

The function _pink_process_vm_readv is returning -1 which is the negated errno value EPERM. This makes pink_vm_cread_nul fail with -1 which in turn makes pink_read_vm_data_nul return -1 which in turn makes syd_read_string function to call panic(). Now we have a detailed information about the panic happening.

Another valuable tool to aid in debugging system call inspection is strace. Let’s check with strace what these stat(2) system calls’ arguments are. I have not updated my strace.git tree for a while and trying to compile it I have found a problem due to an inconsistency between glibc and linux kernel headers which keruspe fixed for pinktrace with commit e1aa031 a week ago:

alip@hayalet ~/src/strace (git)-[master] % make -j1
...
gcc -DHAVE_CONFIG_H -I.  -I./linux/x86_64 -I./linux -I./linux  -Wall -Wwrite-strings -D__ALIP_WAS_HERE -g -ggdb3 -O2 -march=native -D__PINK_IS_BEHIND_THE_WALL -MT process.o -MD -MP -MF .deps/process.Tpo -c -o process.o process.c
In file included from process.c:66:0:
/usr/include/linux/ptrace.h:58:8: hata: 'struct ptrace_peeksiginfo_args' yeniden tanımlanmış
 struct ptrace_peeksiginfo_args {
        ^
In file included from defs.h:169:0,
                 from process.c:37:
/usr/include/sys/ptrace.h:191:8: bilgi: originally defined here
 struct ptrace_peeksiginfo_args
        ^

struct ptrace_peeksiginfo_args is a recent addition to ptrace.h headers and both sys/ptrace.h of glibc-2.18 and linux/ptrace.h of Linux define it. Thus defining the same struct twice fails. Fortunately we have seen this error before with the IA64 architecture where the same happens with struct pt_all_user_regs and struct ia64_fpreg.

Having hit another totally unrelated bug, I have prepared a patch and tested it:

alip@hayalet ~/src/strace (git)-[master] % make
gcc -Wall -Wwrite-strings -D__ALIP_WAS_HERE -g -ggdb3 -O2 -march=native -D__PINK_IS_BEHIND_THE_WALL   -o strace bjm.o block.o count.o desc.o file.o io.o ioctl.o ipc.o loop.o mem.o mtd.o net.o pathtrace.o process.o quota.o resource.o scsi.o signal.o sock.o strace.o stream.o syscall.o system.o term.o time.o util.o vsprintf.o  
make[2]: `/home/alip/src/strace' dizininden çıkılıyor
make[1]: `/home/alip/src/strace' dizininden çıkılıyor

It compiles and runs fine. Time to prepare a git-format-patch and send to strace-devel mailing list. These git tools make it really easy to prepare patches and submit them. Here is the link to the actual mail.

So far so good. Another bug fixed and submitted upstream. Let’s go ahead and see whether strace can make sense of those stat(2) arguments:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ~/src/strace/strace -f -e stat ./a.out
Process 18698 attached
[pid 18697] +++ exited with 0 +++
stat(0x9db090, {...})                   = 0
stat(0x485897, {...})                   = 0
stat(0x485897, {...})                   = 0
...

Note the -f argument. Remember our panic line started with bash[31387.0:31386] this does not happen in my small program but in bash which is spawned right after fork(2). The -f argument of strace follows forks.

Now the question is what those hex values in the first arguments are. strace usually does a good job in decoding strings so something is weird going on here. Let’s go one step ahead and try to trace strace using strace itself. One has to be careful here not to use -f with the first strace because only one process may trace a process at a time and we want the first strace to only trace strace not our small program a.out. We also use the option -e 'signal=!all' so that we filter some of the unwanted output:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % strace -q -e 'process_vm_readv' -e 'signal=!all' -- strace -e 'signal=!all' -f -e stat ./a.out
getauxval(23) = 0 (errno:0 Success)
Process 22286 attached
[pid 22285] +++ exited with 0 +++
process_vm_readv(22286, 0x7fff71faed40, 1, 0x7fff71faed50, 1, 0) = -1 EPERM (Operation not permitted)
stat(0x1938070, process_vm_readv(22286, 0x7fff71fafce0, 1, 0x7fff71fafcf0, 1, 0) = -1 EPERM (Operation not permitted)
{...})       = 0

The output of the two strace processes are mixed but here we can also see that the system call process_vm_readv() returns the error condition EPERM. Consulting the process_vm_readv(2) manual page:

EPERM  The caller does not have permission to access the address space of the process pid.

Now, why on earth is ptrace() is permitted but process_vm_readv() is not? It is clear that they are two different APIs. It is time to dig into the kernel source. Having walked through the kernel code on lxr for a while, I figured this sydbox-1 PANIC was due to the fact that I have the sysctl kernel.yama.ptrace_scope set to 1 which is YAMA restricting ptrace(). After:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % sudo sysctl kernel.yama.ptrace_scope=0
kernel.yama.ptrace_scope = 0

Everything works OK and now I am aware of the fact that there is another way to restrict ptrace() and I will work on sydbox-1 to make it handle such errors gracefully (without hanging) but that’s for another night.

Confession: I started working at Özgür Yazılım A.Ş. as a Linux system administrator and programmer and I have been using Arch Linux for a while which means I have not been configuring/compiling my own kernel. This was a nice message to me that I should stop being a slacker and return to Exherbo now.

The Exherbo bug 369 is still not fixed, but I am working on it :-)

September 24, 2013 07:00 AM

September 21, 2013

Ali Polatel

Killing tracees on exit with sydbox-1

As I’ve written in my blog post Recent Linux changes to help sandboxing Linux has a few new features which may aid in enhancing sydbox-1.

One of these features is PTRACE_O_EXITKILL. This is a new ptrace option to kill tracees upon tracer exit. Quoting from ptrace(2)

    PTRACE_O_EXITKILL (since Linux 3.8)
        If a tracer sets this flag, a SIGKILL signal will be sent to every
        tracee if the tracer exits.  This option is useful for ptrace
        jailers  that want to ensure that tracees can never escape the
        tracer's control.

This is a simple feature providing a nice enhancement. sydbox-1 had a similar feature to prevent tracees from running upon an abnormal exit. There are two options, namely core/abort/decision and core/panic/decision, which when given the value killall sends SIGKILL to all traced processes upon abnormal exit. There is also the option core/trace/exit_wait_all to make sydbox-1 wait for all tracees to exit before exiting.

However, doing this in user-space is tricky and error-prone. Considering it’s the tracer who is dying unexpectedly, it may not always be possible to kill tracees which will then run in potentially unsafe mode. You can read this lkml thread and many more to dive into the internals of ptrace(2).

Thus, sydbox-1 learned a new magic command with the name core/trace/exit_kill to turn this functionality on with the two commits I pushed to master today:

One restriction is the option core/trace/exit_kill is only useful when it is set upon startup. It does not work with the magic stat() system call. ptrace(2) options are inherited from parent to children thus trying to set this on a per-tracee basis requires one to change the value of the option for the parent and all its children. Although this is possible in theory (sydbox-1 keeps track of parent<->children relationships) it would add some complexity to the program which I do not want unless I see a well-founded reason to do so.

September 21, 2013 07:00 AM

September 14, 2013

Alexander Færøy

Enhancing SSL Security for IRC: DANE Support

A couple of weeks ago, I had a discussion with some of the Quakenet coders on how to add SSL support to their IRC daemon, but the discussion ended up being about the false sense of security that SSL potentially can give to the user. The Quakenet hackers have an interesting article online about their thoughts on the matter and while I do understand their points, I do not agree with it being a good enough reason to completely avoid SSL on your IRC network.

We quickly changed the discussion to be about how the IRC clients should be able to verify that the SSL certificate, received from the server, is not a malicious certificate from someone doing MITM attacks. This was not the discussion I had hoped for, but nevertheless, it was an interesting discussion to participate in and made me spend a few days thinking about their concerns.

Sadly, as it is today, some IRC clients, including Irssi, only do full SSL certificate validation as an opt-in option (via the -ssl_verify option for /connect in Irssi’s case) rather than having it as an opt-out option, which would be ideal. This is simply because people in the IRC community have historically not wanted to spend money on certificates from the so called “trusted” Certificate Authorities like we have seen on the web. Changing this from opt-in to opt-out is something that I would like to see happen, but it is not something that is going to be easy. We saw how many web sites got a “proper” certificate after the Mozilla guys made it slightly harder to actually mark a self-signed certificate as trusted. This was at first a very annoying move, but these days we rarely see self signed certificates when we browse around the web.

A few days after the discussion on IRC, I was having dinner at Thomas’s place and I mentioned the discussion with the Quakenet hackers. Thomas knows a lot about security, privacy and DNS, and he is an avid Quakenet user, so it appeared more than obvious to take the discussion with him and hear what his take to the problem was. His suggestion was to take a look at DNSSEC and DANE and see if that could be used as a possible solution.

Luckily for me, it was exactly what I was looking for.

A few days after the dinner conversation, I pushed a patch to Irssi’s source code repository that enabled support for DANE validation of SSL certificates.

Let’s have a look at how DANE works. This will hopefully give you enough knowledge to understand the basics of what is going on. I will document how to compile Irssi with DANE support enabled and test whether it works or not.

What is DANE?

DANE is an acronym for “DNS-Based Authentication of Named Entities” and comes with a protocol named TLSA. DANE is an internet standard and you can read the full technical specification of DANE in RFC6698, but hopefully, this article will give you an introduction to get started using DANE for your IRC servers right away. The concepts are totally protocol agnostic so this will work for other protocols than IRC as well, but it does require modification to the client software to work.

DANE is a simple way of storing information about a certificate in the DNS system. Adding DNSSEC on top of the cake, gives you a very powerful way of validating certificates where the client relies on a trusted source (their ISP’s DNS server and DNSSEC) validating the information from the possibly eavesdropped IRC server.

DANE is implemented as a new DNS resource record named TLSA. You can see an example of such record here from our test IRC server linked to the IRCsource IRC network:

$ dig TLSA _6697._tcp.ircsource.baconsvin.org

; <<>> DiG 9.8.3-P1 <<>> TLSA _6697._tcp.ircsource.baconsvin.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38406
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 9

;; QUESTION SECTION:
;_6697._tcp.ircsource.baconsvin.org. IN TLSA

;; ANSWER SECTION:
_6697._tcp.ircsource.baconsvin.org. 3358 IN TLSA 3 0 1 9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94

;; AUTHORITY SECTION:
baconsvin.org.      50607   IN  NS  ns1.gratisdns.dk.
baconsvin.org.      50607   IN  NS  ns5.gratisdns.dk.
baconsvin.org.      50607   IN  NS  ns3.gratisdns.dk.
baconsvin.org.      50607   IN  NS  ns2.gratisdns.dk.
baconsvin.org.      50607   IN  NS  ns4.gratisdns.dk.

;; ADDITIONAL SECTION:
ns1.gratisdns.dk.   7417    IN  A       109.238.48.13
ns1.gratisdns.dk.   36319   IN  AAAA    2a02:9d0:3002:1::2
ns2.gratisdns.dk.   25447   IN  A       185.10.10.53
ns3.gratisdns.dk.   31182   IN  A       194.0.2.6
ns3.gratisdns.dk.   28269   IN  AAAA    2001:678:5::6
ns4.gratisdns.dk.   31182   IN  A       87.73.3.3
ns4.gratisdns.dk.   28269   IN  AAAA    2a01:558:4000::3
ns5.gratisdns.dk.   25447   IN  A       85.17.221.46
ns5.gratisdns.dk.   28269   IN  AAAA    2001:6f8:3ad::1

;; Query time: 55 msec
;; SERVER: 89.233.43.71#53(89.233.43.71)
;; WHEN: Sat Aug 10 13:16:23 2013
;; MSG SIZE  rcvd: 393

Note: If your version of dig doesn’t recognize the TLSA type, you can easily replace it with TYPE52 like this: dig _6697._tcp.ircsource.baconsvin.org TYPE52.

Notice how the port, 6697, and protocol, TCP, is part of the DNS query. This will be familiar for people who have worked with SRV DNS records.

The interesting part of the output is the answer section where you see the following:

3 0 1 9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94

What does all of this mean?

Let’s start out by looking at the format. The format for a TLSA reply is as following:

<certificate usage> <selector> <matching type> <certificate association data>

This means that our certificate usage field is 3, our selector is 0 and our matching type is 1. The associated data is the string "9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94".

It is important to understand the semantics of these fields, because they will dictate how and if the client is going to do further validation of the certificate once the client has received it from the IRC daemon.

Using 3 0 1 means that we are using a self-signed certificate and we will rely on DANE for validating the certificate only (3); that we are using the full certificate and not just the SubjectPublicKeyInfo part (0) and we will be using a hexadecimal encoded SHA256 hash of the DER-encoded certificate (1).

To fully understand the various options available, I suggest you take a look at RFC 6698 section 2.1.

Enable DANE Support for your IRC Server

The first step you will have to take is to ensure that whoever runs your DNS servers supports both DNSSEC and TLSA records. In Denmark, a lot of users are using the free DNS hosting provider GratisDNS. GratisDNS supports both DNSSEC and TLSA records which makes setting this up a lot easier.

Sadly, GratisDNS’ interface is currently only available in Danish, so you might have to look for other solutions available online.

Once you have a DNS provider that supports DNSSEC and TLSA records, it is fairly easy to create the records. In our example, the following assumptions are made:

  1. You already have an IRC daemon running with SSL enabled on port 6697 and you have verified that it actually works as expected.

  2. Your certificate is self-signed, so you would like to rely on DANE support only for the validation. This means that the user will not see any self-signed certificate errors when connecting with certificate validation enabled.

  3. We will create a record using a SHA-256 hash of the certificate data. Feel free to use something stronger, if you are more crypto paranoid than I am.

This means that our TLSA record will end up looking something similar to this:

_6697._tcp.irc.example.org TLSA 3 0 1 <SHA-256 hash of the certificate data>

This is basically going to be a description of the exact same setup that I am using for ircsource.baconsvin.org.

To find the SHA-256 value of your certificate, start by logging onto the server running the IRC daemon and find the directory that contains your certificate files. We are then going to find the SHA-256 value of the DER representation of our certificate:

$ openssl x509 -in ircsource.baconsvin.org.pem -outform DER | sha256sum
9b954a014881108a9058db80020909ffd8b4c44c6f41c8796b3a1ea43a444b94  -

This is the value we will be using in our final TLSA record, which now looks like the following:

_6697._tcp.irc.example.net TLSA 3 0 1 9b954a014881108a9058db80020909ffd8b4c44c6f41c8796b3a1ea43a444b94

Once you have added this record to your DNS zones, it is now time to actually test whether it works as expected.

Building Irssi with DANE Support

This part is tested on FreeBSD 9.2-PRERELEASE. Hopefully, it works for other people as well. Feel free to report any issues you may experience.

  1. Download the dnsval tarball from its download page. This is quite new software so I haven’t run into many distributions that have packages available, so we will assume that we have to compile it ourselves.

    $ mkdir dane
    $ cd dane
    $ fetch http://www.dnssec-tools.org/download/dnsval-2.0.tar.gz
    $ tar zxfv dnsval-2.0.tar.gz
    $ cd dnsval-2.0
    $ ./configure --prefix=/usr/local
    $ make
    $ sudo make install
    
  2. Next we will download the Irssi source code from the Git repository. We start by cloning the repository into our newly created dane directory:

    $ cd dane
    $ git clone git://git.irssi.org/irssi
    $ cd irssi
    
  3. We bootstrap the build system:

    $ sh autogen.sh
    
  4. We configure our test Irssi client:

    $ CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure --enable-dane --with-perl=no
    

    Make sure that somewhere near the end of the output of the configure script contains:

    Building with DANE support ....... : yes
    

    Otherwise you should take a look at the config.log file and look for places where libval is mentioned and figure out why it doesn’t find the library correctly.

  5. Compile Irssi:

    $ make
    
  6. Fire up your new Irssi client and give it a spin:

    $ ./src/fe-text/irssi -!
    
  7. Try to connect to our test server, ircsource.baconsvin.org, using DANE:

    /connect -ssl -ssl_verify ircsource.baconsvin.org 6697
    

    If everything was done correctly, Irssi will now connect to the server, verify the signature of the certificate using TLSA and allow you to connect without seeing any self-signed certificate errors.

DANE Enabled IRC Servers

Here’s a list of IRC servers that supports DANE. If you are running a public IRC server and would like to see the server added here, feel free to drop me an email at ahf@irc6.net with information about the server.

IRCsource

IRCsource is a small network where people with a general interest in IRC hang out together to discuss and test various new concepts and ideas for IRC.

  • ircsource.baconsvin.org (SSL ports: 6697 and 9999)

I will do my best to maintain this list of servers supporting DANE in the future.

Next Stop?

The next step for me is to start securing server-to-server links within the IRC networks with DANE. This will require some modifications to the IRC daemons themselves. I plan on looking into adding support for DANE in a personal feature branch of ircd-ratbox and some of its derivatives.

Conclusion

I am unable to say if DANE support is what the IRC community will be adopting. The IRC community is very conservative in general so time will have to tell.

If you believe you have found a bug in my code or have any troubles setting DANE up for your own IRC server, I will be more than happy to help. Drop me an email and I will take a look at it whenever I have time. Otherwise, feel free to poke me on IRC. My nickname is ahf and I am available on most of the “larger” IRC networks (EFnet, Freenode, IRCnet and Quakenet).

All of this code will be available in the upcoming Irssi 0.8.16 release, but if you want to test it right away, my suggestion is to follow my guide from above and use Irssi directly from Git.

Hopefully, we will see other IRC client and server hackers implementing DANE support in the nearby future. If you like what you have read here, please help me making this happen by spreading the word about the possibilities available for enhancing the SSL support in IRC clients as well as other SSL based online services.

This is too easily implementable to be ignored.

Credits

I would like to thank Thomas Steen Ramussen for being the originator of the idea and setting up the initial DNS server for testing purpose; Peter Larsen for expeditiously implementing TLSA support for GratisDNS; the IRC6.net guys for late night discussions about DANE; Mickey Fischer for testing the Irssi patches on Gentoo Linux with various options enabled and disabled; the DNSSEC-Tools Project for creating the libraries used and finally the rest of the Irssi team for reviewing the patches and coming with recommendations for my code.

September 14, 2013 12:00 AM

September 13, 2013

Wulf C. Krueger

You all suck at working on patches, my fellow Exherbo devs!

I originally posted this in 2011. Unfortunately, hardly any significantly changed since then. I decided to add !pd statistics this time, though:

Philantrop: 557
sepek: 271
ar: 207
keruspe: 180
SardemFF7: 105
zlin: 98
compnerd: 94
sepek_: 88
SuperHeron: 67
heirecka: 53
moben: 43
mrothe: 37
woutershep: 33
pipping: 33
Bruners: 33
virkony: 30
arnej: 27
nicoo: 24
tgurr: 22
freeedrich|: 22

 

 

What really annoys me lately is the unwillingness of my fellow Exherbo core developers to act on user-contributed patches. While it’s certainly true that some patches need extensive testing and, thus, require a lot of time, there are usually a lot of trivial patches or patches that can be tested with moderate effort.

Let’s look at an example:

From 2a11f609e8be4f61a545112f1fceda6f8c40bfeb Mon Sep 17 00:00:00 2001

From: Johannes Nixdorf <mixi@user-helfen-usern.de>

Date: Thu, 24 Mar 2011 16:26:59 +0100

Subject: [PATCH] revive agg in ::mixi

drizzt.graveyard | 7 ——-

1 files changed, 0 insertions(+), 7 deletions(-)

diff –git a/drizzt.graveyard b/drizzt.graveyard

index 98979b9..92ed79a 100644

— a/drizzt.graveyard

+++ b/drizzt.graveyard

@@ -287,10 +287,3 @@ www-servers/

homepage = http://nginx.net

removed-by = Wulf C. Krueger <philantrop@exherbo.org>

removed-from = drizzt

-x11-libs/

- agg/

- :0 2.5

- description = A High Quality Rendering Engine for C++

- homepage = http://antigrain.com/

- removed-by = Wulf C. Krueger <philantrop@exherbo.org>

- removed-from = drizzt

1.7.4.1

This patch was for ::graveyard. It simply removes a single entry for a package that found a new home since I removed it. Great!

Anyone with push access could have verified and pushed it with minimal effort and, yet, nobody did for about two days and I’m pretty sure it would still be rotting on zebrapig if I hadn’t done so today.

Unfortunately, it’s by far not the only example. At the time of writing, zebrapig keeps 16 patches. A week ago, it were over 30. Nobody gave a shit.

There are patches that have been on zebrapig for months now (Ruby comes to mind!) and help with them is rejected because some people have worked on them and instead of submitting improved patches, they keep them to themselves, effectively stopping anyone from doing anything. And hardly anyone gives a shit.

Now, why is that situation so bad:

  1. Patches are submitted to improve Exherbo. You’re impeding improvement by ignoring them.
  2. Patches are submitted by our contributors/non-core developers. If you ignore their patches, they will become frustrated and stop submitting patches but create their own repositories, duplicating our work and making things harder for all of us. Or they will just go away. The latter is the worst possible outcome for Exherbo as a whole because with hardly more than a handful of active core developers, we will fail if we drive contributors away.
  3. You’re putting more workload on the even fewer people with push access that actually work on patches. This takes away from our time working on more interesting stuff and, at least in my case, really alienates people from Exherbo.

Effectively, I’m handling most of the contributed patches myself. Either by reviewing, discussing and pushing them myself or by asking people to work on them (and usually getting stupid answers…).

Another thing that annoys me greatly are the answers I’m getting from people I’m asking to review patches; here are some examples (in no particular order) and what I think about them (which is usually not what I say):

  • “I prefer playing SC2.” / “I’m watching Star Trek!” – Well, yes, fine but I’m sure you could really dedicate at least one or two hours per week to work on patches.
  • “Exherbo is just something nice to play with. I don’t really want to really work on it or be professional about it.” – (I really hate that one.) If you take up responsibility for something, even as a hobby or so, then live up to it or leave it be. Get used to behaving professionally now while you can afford it not to be. Once you get a job, people won’t be so forgiving.
  • “I don’t really care about that package anymore.” – Well, I don’t either but there’s a patch so other people obviously do care. If you really want to get rid of a package, mail the exherbo-dev mailinglist and tell people. If there’s no taker, use Dexter to bury the package if need be.
  • “I prefer vodka over patches.” – …
  • “I’m working! Not a student anymore.” / “I’m so tired!” – So am I. And I’m married, have three kids and two rabbits. I’m working hard myself so you have my sympathy but, really, are one or two hours per week too much to ask? I usually invest much more time myself.
  • “I’ve been busy slacking for a year!” (or longer) – Then please make it official and resign as a core developer. At least I’m going to know whom not to ask and it’ll become more obvious we’re under-staffed.
  • “I said I’d do it but now I can’t be arsed.” – Great, you could at least have told me right from the start you’re not going to do anything. I could have acted accordingly then.

And sometimes, the very same people who just refused to even look at a patch will ask me to review their patches seconds later…

All of this is really annoying and it’s the most likely reason for me to quit working on Exherbo and switching all my machines to another Linux distribution at some point if we don’t find a solution.

by Wulf Krueger at September 13, 2013 05:14 PM

September 02, 2013

Ciaran McCreesh

Paludis 1.4.1 Released

Paludis 1.4.1 has been released:

  • Compatibility with newer Boost.
  • Minor bug fixes and UI tweaks.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at September 02, 2013 01:00 PM

June 27, 2013

Ali Polatel

Sandboxing Skype with sydbox-1

There are various tools to provide enhanced restriction mechanisms under Linux. In case security is the major concern, these mechanisms need to be in the kernel level which in turn means specific configurations or in some cases modifications (in forms of patches etc.) to the Linux kernel. Some examples are AppArmor, Security Enhanced Linux, Tomoyo Linux, and Grsecurity. User space solutions are either not as flexible or not as secure depending on the use case scenario.

We, at Exherbo, need a sandbox for misbehaving package builds. One should note that such misbehaviours can sometimes be rather fun (or not safe for work at times). I used the term misbehaving on purpose because this does not mean the sandbox itself can make the build environment totally secure. Linux has good old UNIX goodies like separate permissions for users, chroots and new shiny stuff like per-process namespaces to implement further restrictions.

Exherbo’s practical solution to this issue is sydbox. With the upcoming version sydbox-1 - which is yet to be released - this solution can easily be adapted to different use cases.

As I was browsing through Arch Linux Wiki pages I stumbled upon the Skype page which describes different approaches to restrict such close sourced applications.

I am not claiming using sydbox-1 for this purpose is secure but it is most certainly practical. Here is my proof-of-concept attempt at sandboxing Skype using sydbox-1. Below is a sample sydbox-1 profile for use with Skype. You can also find it in sydbox-1.git under examples/ directory.

    # sydbox profile for Skype4

    #
    # Sandboxing
    #
    core/sandbox/exec:deny
    core/sandbox/read:deny
    core/sandbox/write:deny
    core/sandbox/network:deny

    core/whitelist/per_process_directories:true
    core/whitelist/successful_bind:true
    core/whitelist/unsupported_socket_families:true

    core/abort/decision:killall
    core/panic/decision:kill
    core/panic/exit_code:-1
    core/violation/decision:deny
    core/violation/exit_code:-1
    core/violation/raise_fail:false
    core/violation/raise_safe:false

    core/trace/follow_fork:true
    core/trace/exit_wait_all:true
    core/trace/magic_lock:off
    core/trace/interrupt:while_wait
    core/trace/use_seccomp:true
    core/trace/use_seize:true
    core/trace/use_toolong_hack:true

    core/match/case_sensitive:true
    core/match/no_wildcard:literal

    #
    # Logging
    #
    log/file:
    log/level:511
    log/console_fd:2
    log/console_level:3

    #
    # /dev
    #
    whitelist/read+/dev
    whitelist/read+/dev/urandom
    whitelist/read+/dev/stdout
    whitelist/read+/dev/stderr
    whitelist/write+/dev/tty*
    whitelist/write+/dev/pts/***
    whitelist/read+/dev/snd/***
    whitelist/write+/dev/snd/***
    whitelist/read+/dev/video*
    whitelist/write+/dev/video*

    #
    # /proc & /sys
    #
    whitelist/read+/proc/cpuinfo
    whitelist/read+/proc/meminfo
    whitelist/read+/proc/stat
    whitelist/read+/proc/net
    whitelist/read+/proc/net/arp
    whitelist/read+/proc/net/route
    whitelist/read+/proc/net/unix
    whitelist/read+/proc/sys/vm/overcommit_memory
    whitelist/read+/proc/sys/kernel/osrelease
    whitelist/read+/proc/sys/kernel/ostype
    whitelist/read+/sys/devices/system/cpu/online
    whitelist/read+/sys/devices/system/cpu
    whitelist/read+/sys/devices/system/cpu/cpu?/cpufreq/scaling_cur_freq
    whitelist/read+/sys/devices/system/cpu/cpu?/cpufreq/scaling_max_freq
    whitelist/read+/sys/devices/virtual/dmi/id/board_name
    whitelist/read+/sys/devices/virtual/dmi/id/board_version
    whitelist/read+/sys/devices/virtual/dmi/id/board_vendor
    whitelist/read+/sys/devices/virtual/dmi/id/product_name
    whitelist/read+/sys/devices/virtual/dmi/id/product_version
    whitelist/read+/sys/devices/virtual/dmi/id/sys_vendor
    whitelist/read+/sys/devices/*/*/*/power_supply/ACAD/***
    whitelist/read+/sys/devices/*/*/*/*/*/*/modalias
    whitelist/read+/sys/devices/*/*/*/*/*/*/video4linux/video?/dev
    whitelist/read+/sys/devices/*/*/*/*/*/idProduct
    whitelist/read+/sys/devices/*/*/*/*/*/idVendor
    whitelist/read+/sys/devices/*/*/*/*/*/speed

    #
    # nscd (glibc)
    #
    whitelist/network/connect+unix:/var/run/nscd/socket
    whitelist/network/connect+unix:/run/nscd/socket

    #
    # /etc
    #
    whitelist/read+/etc/asound.conf
    whitelist/read+/etc/group
    whitelist/read+/etc/hosts
    whitelist/read+/etc/host.conf
    whitelist/read+/etc/ld.so.cache
    whitelist/read+/etc/ld.so.preload
    whitelist/read+/etc/nsswitch.conf
    whitelist/read+/etc/resolv.conf
    whitelist/read+/etc/ssl/certs/***
    whitelist/read+/etc/fonts/***
    whitelist/read+/etc/gtk-2.0/***
    whitelist/read+/etc/pango/***

    #
    # Libraries
    #
    whitelist/read+/lib*/***
    whitelist/read+/usr/lib*/***

    #
    # Share dirs
    #
    whitelist/read+/usr/share/alsa/***
    whitelist/read+/usr/share/ca-certificates/***
    whitelist/read+/usr/share/locale/***
    whitelist/read+/usr/share/zoneinfo/***
    whitelist/read+/usr/share/fonts/***
    whitelist/read+/usr/share/icons/***
    whitelist/read+/usr/share/pixmaps/***
    whitelist/read+/usr/share/texmf-dist/fonts/***
    whitelist/read+/usr/share/X11/***

    #
    # Xorg/X11 & dbus
    #
    whitelist/network/connect+unix-abstract:/tmp/.X11-unix/**
    whitelist/network/connect+unix-abstract:/tmp/.ICE-unix/**
    whitelist/network/connect+unix-abstract:/tmp/dbus-*
    whitelist/network/connect+unix:/run/dbus/system_bus_socket
    whitelist/network/connect+unix:/var/run/dbus/system_bus_socket

    #
    # /tmp
    #
    whitelist/read+/tmp/qtsingleapp-*
    whitelist/write+/tmp/qtsingleapp-*
    whitelist/network/bind+unix:/tmp/qtsingleapp-*
    whitelist/network/connect+unix:/tmp/qtsingleapp-*

    #
    # Skype
    #
    whitelist/read+/etc/Skype.conf
    whitelist/read+/etc/Skype/***
    whitelist/read+/usr/*bin/skype
    whitelist/exec+/usr/*bin/skype
    whitelist/exec+/usr/lib*/skype/skype
    whitelist/exec+/opt/skype/skype
    whitelist/read+/opt/skype/***
    whitelist/read+/usr/share/skype/***

    #
    # Host specific configuration under /home
    #
    whitelist/read+/home/*/.Xauthority
    whitelist/read+/home/*/.ICEauthority
    whitelist/read+/home/*/.gtkrc*
    whitelist/read+/home/*/.config/Trolltech.conf
    whitelist/write+/home/*/.icons/***

    #
    # Skype specific configuration
    #
    whitelist/read+/home/*/.asoundrc
    whitelist/read+/home/*/.config/Skype/***
    whitelist/write+/home/*/.config/Skype/***
    whitelist/read+/home/*/.Skype/***
    whitelist/write+/home/*/.Skype/***

    #
    # Temporary files & caches
    #
    whitelist/read+/home/*/.cache/fontconfig/***
    whitelist/write+/home/*/.cache/fontconfig/***
    whitelist/read+/home/*/.compose-cache/***
    whitelist/write+/home/*/.compose-cache/***

    #
    # Networking
    #
    # note: allow IPv4 and IPv6 by default since Skype operates on a P2P model.
    #       You may further restrict access by only allowing access to SKYPENET,
    #       Akamai and Microsoft Corporation together with your contact's IP
    #       address.
    #
    whitelist/network/bind+LOOPBACK@0
    whitelist/network/connect+inet:0.0.0.0/0@0-65000
    whitelist/network/connect+inet6:::0/0@0-65000

    #
    # Allow some external programs
    #
    whitelist/exec+/usr/*bin/xdg-open
    exec/resume_if_match+/usr/*bin/xdg-open

A couple of things to note:

  1. sydbox-1 is still in heavy development and the file format may change.
  2. This approach is not secure. Author claims no responsibility if Skype kills your goats.
  3. Three is the loneliest number since number two which is the loneliest number since the number one.

Happy hacking!

June 27, 2013 07:00 AM

June 13, 2013

Ali Polatel

I Can Not Tell

As the Garip poet Orhan Veli once wrote,

Can you hear me if I cry,
In my verses;
Can you touch,
My tears, with your hands?

I hadn't known how songs were so lovely,
And yet the words so inadequate
Before I had fallen into this suffering.

I know there is somewhere
To say anything about which is possible;
I am very close, I can hear;
I can not tell...

in his poem Anlatamıyorum (I Can Not Tell, translated by myself on 2013-06-13). Sometimes a photo may describe what we can’t describe with a thousand words.

You know your government has failed, when your grandma starts to riot!

Long story short, you know your government has failed, when your grandma starts to riot

Occupy Gezi! Diren Gezi!

Update

  • 2013-06-14: Translation of the first quatrain was slightly modified.
  • 2013-06-16: More translation fixes.

June 13, 2013 07:00 AM

May 16, 2013

Ciaran McCreesh

Paludis 1.4.0 Released

Paludis 1.4.0 has been released:

  • Tweaked ‘cave resolve’ output to add blank lines.
  • Support for libarchive 3.1.2.
  • Compatibility fixes for GCC 4.8.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at May 16, 2013 01:29 PM

April 02, 2013

Ali Polatel

Tragedy of a Trachian Soldier

Here is a brief attempt to translate the nervous breakdown of a Trachian soldier after 6 hours of sentry-duty… As a show of respect to the soldier, the f-word has been substituted with the word love on all occurences.

That’s it, love it! That’s it, love it!
I’ve had enough of this duty!
I’ve been here for 6 hours, love it!
Love who put me here, love who made him put me here! Love ‘em all!
Lovers trusting me to secure this huge company!
What is this? That tears it! Love it!
What is this? Love it!
What is this? Am I an animal? Love it!
Are my parents cows?!!
No more of this loving duty!
No more I am no part of it! Love it!
Cameraman: Yeah, lie down, chill!
What is this? Who the love does he think he is? Love him too!
Cameraman: Enough already!

April 02, 2013 07:00 AM

March 25, 2013

Ciaran McCreesh

Paludis 1.2.0 Released

Paludis 1.2.0 has been released:

  • Bug fixes.
  • Dep specs can now use ‘[.key!=value]‘. The behaviour of ‘<‘ and ‘>’ has changed: for key types where order comparisons don’t make sense, the match now always fails.
  • Various compiler-compatibility fixes.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at March 25, 2013 06:51 PM

March 08, 2013

Wulf C. Krueger

HowTo: systemd on Exherbo

This comes up all too often, so here’s a HowTo for systemd on Exherbo:

  • You have to run a Linux kernel >=2.6.39. The new kernel is only needed at runtime, not for building systemd.
  • You should run a Linux kernel >=3.8. The new kernel is only needed at runtime, not for building systemd.
  • Kernel options for systemd: cf. systemd’s README, here’s an excerpt:

CONFIG_DEVTMPFS
CONFIG_CGROUPS (it’s OK to disable all controllers)
CONFIG_INOTIFY_USER
CONFIG_SIGNALFD
CONFIG_TIMERFD
CONFIG_EPOLL
CONFIG_NET
CONFIG_SYSFS

Linux kernel >= 3.8 for Smack support

Udev will fail to work with the legacy layout:
CONFIG_SYSFS_DEPRECATED=n

Legacy hotplug slows down the system and confuses udev:
CONFIG_UEVENT_HELPER_PATH=”"

Userspace firmware loading is deprecated, will go away, and
sometimes causes problems:
CONFIG_FW_LOADER_USER_HELPER=n

Some udev rules and virtualization detection relies on it:
CONFIG_DMIID

Mount and bind mount handling might require it:
CONFIG_FHANDLE

Optional but strongly recommended:
CONFIG_IPV6
CONFIG_AUTOFS4_FS
CONFIG_TMPFS_POSIX_ACL
CONFIG_TMPFS_XATTR
CONFIG_SECCOMP

For systemd-bootchart a kernel with procfs support and several
proc output options enabled is required:
CONFIG_PROC_FS
CONFIG_SCHEDSTATS
CONFIG_SCHED_DEBUG

For UEFI systems:

CONFIG_EFI_VARS
CONFIG_EFI_PARTITION

Furthermore:
CONFIG_FANOTIFY=y (only used for readahead stuff which is not enabled by default.)

CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y (only used for readahead stuff which is not enabled by default.)

 

  • Set the “systemd” option globally in /etc/paludis/options.conf: */* systemd
  • Install systemd: cave resolve -x sys-apps/systemd (Read what cave tells you. If in doubt, read Paludis’ documentation.)
  • Reinstall every package with the new option set: cave resolve world -cx
  • Switch to systemd as your init system: eclectic init set systemd
  • Set the desired hostname in /etc/hostname.
  • Optional: Edit /etc/vconsole.conf to your liking. (If you delete it, empty it or comment out everything, systemd will use the kernel’s defaults.)
  • Optional: Edit /etc/machine-info to your liking.
  • Read Lennart’s blog post about the other configuration files.
  • Install a Linux kernel >=2.6.39. (see above for kernel options, etc.)
  • Reboot.

After that reboot, you’ll be in a console with a minimal set of services started, hopefully ready to log in. Log in as root (the keyboard layout is set to US in vconsole.conf (see above) by default!). Then you can enable whatever services (found in /lib/systemd/system) you like, suggested ones are:

  • dhcpcd.service or NetworkManager.service
  • sshd.socket (it doesn’t start? Missing host keys? man sshd or http://tinyurl.com/24jwxjd)

As an extremely simple and limited alternative to NetworkManager.service, there’s network.service and network.conf which get installed if you set the “simple-net” option for systemd. network.service only allows for static network setups with IPv4.

Alternatively, you can use dhcpcd.service.

If I were you, I’d not enable your display manager’s service (either kdm.service, gdm.service, xdm.service or slim.service) until your basic system has at least booted properly once and you can reach your system using ssh because in case things go wrong, it’s easier not to have to wrestle with a GUI.

To actually enable a service, run “systemctl enable <foo.service>”. More details can be found in systemd’s man page.

If you need help, it’s available in #exherbo, as usual, but if you didn’t read this before asking, grumpy me will bite your head off unless you prove you read this by saying “I have furuncles on my arse.”. Yes, I’m being serious.

 

FAQ section:

  • “How/where do you specify extra modules to be loaded?” – You put the module name into /etc/modules-load.d/foo.conf and it will get loaded. Unless systemd-udev has already loaded it for you. Check that first.
  • “My hostname is set to something funny, e. g. ’08′!” – If you’re using NetworkManager, you need to set your hostname in /etc/NetworkManager/NetworkManager.conf, too.
  • “I’m getting messages about failing services, e. g. dev-hugepages.mount or sys-kernel-debug.automount. What’s up with that?” – You can either enable the corresponding kernel options, delete the symlink (e. g. /lib/systemd/system/basic.target.wants/sys-kernel-debug.automount) or just ignore those messages. They’re harmless.
  • “When sshd.socket is enabled, every closed ssh connection leaves a failed service around, e. g. sshd@192…:55140.service.” – Harmless as well. There are no ressources used by those so ignore them. (This should be fixed anyway.)
  • “Where can I learn more about the usual administration tasks? – Read Lennart’s series of blog posts about systemd for administrators: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8
  • “How do I debug problems with systemd?” – Read this page http://fedoraproject.org/wiki/How_to_debug_Systemd_problems
  • “I’m completely lost. What do I do?” – Please remember there’s always a friend around. It’s called “man”. ;-)

by Wulf Krueger at March 08, 2013 04:06 PM

March 04, 2013

Bryan Østergaard

Looking for a few more volunteers

It's that time of the year.. Only four days left before the big danish Open Source Days conference starts and we're tying up all the loose ends as quickly as possible.

Things are looking great from my point of view but one of the things we need to sort out before the conference opens is all the different helper roles. And we're still looking for good wanting to be an active part of Open Source Days and get to know all the other great people involved.

If you would like to take part in this you can sign up at Join Us and in return for helping out you get free entrance to the conference including the social event saturday night.

March 04, 2013 11:09 PM

March 03, 2013

Wulf C. Krueger

Multilib migration after The Great Merge (optional)

Disclaimer: The entire migration procedure as described below is completely optional. If you don’t need or want multilib/multibuild/multiple C targets support, you can ignore this email.
We won’t force anyone to use it. I’m only going to use it on my desktop myself. :-)

 

We’ve now merged all multilib branches into master (this will go down into history books as “The Great Merge”!).

Thus, we don’t have any separate branches in our official and dev repositories anymore and if you still have a multilib branch  in your repository, please merge it, too.

Now is a good time to write an updated multilib migration guide so, without further ado, here we go:

  • Switch to the multibuild profile in arbor.conf (${location}/profiles/amd64/multilib)
  • Ensure that CHOST is not set in bashrc, and note that CFLAGS will apply to all C targets. You can use MULTIBUILD_C_{32,64}_USER_C{,XX}FLAGS for individual C targets.
  • Re-install/update sys-apps/skeleton-filesystem-layout
  • Install sys-libs/glibc[bootstrap], note that this should pull in sys-devel/bootstrap-gcc, too. (This is going to take a long time.)
  • Install sys-devel/gcc[-openmp] (This is potentially going to take a long time, especially if you have the java option set.)
  • Use eclectic gcc to switch to the freshly compiled multilib gcc
  • Install sys-libs/glibc[-bootstrap], you can let Paludis purge sys-devel/bootstrap-gcc while doing so.
  • Adjust your options to include the C targets you want and re-install any packages accordingly. You might have to re-install lots of package dependencies to fulfill a newly selected target’s requirements. (I simply did a cave resolve -e world)

Best regards, Wulf

by Wulf Krueger at March 03, 2013 02:08 PM

February 22, 2013

Ali Polatel

Recent Linux changes to help sandboxing

Linux kernel 3.8 has been released this week which reminded me to write about recent Linux kernel changes which may help in improving sydbox. Below is a short summary of new, and not so new, features merely to get myself to stop slacking and start coding again.

Per-process namespace support

Per-process namespace support is completed with linux-3.8. This feature provides a nice way to separate resources on a per-process basis, for example a process might see a set mountpoints, PID numbers, and network stack state, and a process in other namespace might see others. For more information see the Linux-3.8 Changes page on kernelnewbies and the Namespaces in Operation articles on LWN.

PTRACE_O_EXITKILL

New in linux-3.8, this ptrace(2) option makes the tracer send SIGKILL to tracees on exit. This is useful for ptrace(2) based sandboxes for which a resumed tracee is a security risk. See the related commit for more information.

SECCOMP_MODE_FILTER

This is by far my favourite feature. Introduced with Linux kernel 3.5 and also known as seccomp mode 2 or user filters this feature lets you add basic system call filters expressed as Berkeley Packet Filter programs. Even though sydbox still has to use ptrace(2) to do more sophisticated argument checking, this feature removes the need to stop the tracee on every system call entry and exit which is a PITA especially when tracing multithreaded programs. sydbox-1 takes advantage of this feature using SECCOMP_RET_TRACE which signals the tracer with the new ptrace(2) event PTRACE_EVENT_SECCOMP.

Here are some useful links:

PTRACE_SEIZE & PTRACE_INTERRUPT

Probably even older than seccomp user filters, these ptrace requests allow the tracer to attach to tracee without trapping it or affecting its job control states. See, http://thread.gmane.org/gmane.linux.kernel/1136930 for more information.

February 22, 2013 08:00 AM

February 21, 2013

Bryan Østergaard

20.000 minutes

20.000 minutes sounds like a lot but for sufficiently large projects with sharp deadlines it really isn't.

Converted to a more manageable time scale it's roughly two weeks or roughly how much time until the Open Source Days conference opens. As some of you might know this is the second year I'm involved in organising this big open source conference.

And just like last year it's an awesome experience but also very stressful with all the small things needing to fall into place for the conference to run smoothly. And unlike last year I haven't been sick so I'm getting to enjoy the full experience :)

Having only two weeks left means really long hours every day while we scramble to close all the outstanding issues. But it also means we get to see a huge amount of things fall into place each day.

Some of the things I'm excited about today:

  • Most of the talks are now announced on the website

  • The keynote talks are all confirmed. More on that later.

  • We've added several more sponsors

The next two weeks should be very exciting and I'm sure the conference is going to be even better this year.

See you all at the conference!

February 21, 2013 11:13 PM

February 15, 2013

Ali Polatel

The Wall

As I took a sip from my tea, the room felt a bit different. Different in such a way that it enabled me to let my unconscious take over.

The wall I was leaning against seemed to change. It was turning into a door. A door made of small curved mirrors… All paintings on the wall faded away slowly. There I was, left alone with a door to enter. Was this a question of bravery? “Temptation, temptation…” So I heard the voices sing. I must admit, I felt kind of scared. Like a baby felt giving birth to her first mother. Before I could change my mind, I quickly grabbed my book and opened the door. I was expecting a divine forest, green and huge. Quite the contrary, the door led me to another room with mirrors on all of its walls, ceiling and floor. I could see the reflection of everything in the room but not myself. The door had vanished and my book looked a lot different to me. What was it that I was to do here? What exactly did I leave behind? This thought made me smile, like a mother smiled while giving birth to her own mother

Leaving my book in a corner of the room, I observed the mirrors. Why was my reflection not there? In a room like this, how could I see what differences this journey might have made in me? After a couple of minutes, I was surprised to discover that I couldn’t see the reflections of the things that “touched” me. My clothes, my shoes, my earring… All became visible as I took them off. “The book!” I said, “where is it?” turning into the corner where I left it. Its reflection was still there. Looking at me and smiling like my mother smiled, giving birth to my grandmother

Somehow, I knew the cure was in this room but where? The endlessness, which the mirrors have formed, gave me an idea. Why was I thinking that the other side of the mirror was inaccessible to me? “Temptation, temptation…” So I heard the voices sing. I must admit, I felt kind of scared. Like a warrior felt, being slain by his new-born baby… Feeling I might have found the cure, I took a step into the mirror. There I saw my “other” self sitting in that room, looking at the wall, writing a truly odd story… I can’t say he was astonished though, seeing me standing against him, naked.

February 15, 2013 08:00 AM

February 02, 2013

Ciaran McCreesh

Paludis 1.0.0 Released

Paludis 1.0.0 has been released:

  • EAPI 5 style subslot specs are allowed in user dependency specs.
  • We now support DWARF compression.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at February 02, 2013 03:14 PM

November 16, 2012

Ciaran McCreesh

Paludis 0.82.0 Released

Paludis 0.82.0 has been released:

  • Various EAPI 5 related fixes.

Filed under: paludis Tagged: paludis

by Ciaran McCreesh at November 16, 2012 11:46 PM

October 23, 2012

Ali Polatel

Easy on the Eyes

Writing with the intention to grow up:

Rule 1: Stay out of the magical world. This your subconscious speaking.

Rule 2: Never underestimate the power of goats.

Rule 3: Pink Floyd after midnight is easy on the eyes.

Rule ?: Numbers are bad.

Rule: Actually they have no reason whatsoever to even exist.

?: No rule, no pain.

Love: You are on the right path, Watson.

Do not define sizeof(void *). Because in what you would call a primitive world you would only need love, pure, endless love.

Ooomray!

Now look at the sky, look at the river. Isn’t it good?

If not, return to rule 3.

October 23, 2012 07:00 AM

October 19, 2012

Ciaran McCreesh

Paludis 0.80.2 Released

Paludis 0.80.2 has been released:

  • Bug fixes.
  • Added ‘cave print-unmanaged-files’.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at October 19, 2012 02:17 PM

October 13, 2012

Ciaran McCreesh

October 04, 2012

Wulf C. Krueger

systemd and the Linux kernel

This comes up all too often, so here’s a HowTo for systemd on Exherbo:

  • You have to run a Linux kernel >=2.6.39. The new kernel is only needed at runtime, not for building systemd.
  • You should run a Linux kernel >=3.0. The new kernel is only needed at runtime, not for building systemd.
  • Kernel options for systemd: In your kernel config, enable autofs4, devtmpfs and cgroups. Do not enable autofs3. Here’s what I’m using (I enable more kernel options than strictly necessary, though.):

CONFIG_DEVTMPFS=y (Strictly required!)

CONFIG_DEVTMPFS_MOUNT=y (unless you're using an initramfs that's mounting it for you, e. g. one created by Dracut)

# CONFIG_AUTOFS_FS is not set (Strictly required!)

CONFIG_AUTOFS4_FS=y (Strictly required!)

CONFIG_CGROUPS=y (Strictly required!)

# CONFIG_CGROUP_DEBUG is not set

CONFIG_CGROUP_NS=y

CONFIG_CGROUP_FREEZER=y

CONFIG_CGROUP_DEVICE=y

CONFIG_CGROUP_CPUACCT=y

# CONFIG_CGROUP_MEM_RES_CTLR is not set

CONFIG_CGROUP_SCHED=y

CONFIG_BLK_CGROUP=y

# CONFIG_DEBUG_BLK_CGROUP is not set

CONFIG_FANOTIFY=y (only used for readahead stuff which is not enabled by default.)

CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y (only used for readahead stuff which is not enabled by default.)

by Wulf Krueger at October 04, 2012 08:33 AM

September 29, 2012

Ali Polatel

sydbox-1 is nearly there

After nearly two years I began working on a sydbox replacement1 she is finally nearing completion. This post is meant both as a preliminary announcement and help request.

sydbox-1 has been in ::arbor for sometime as sydbox-scm2 and paludis supports it since version 0.78.1. The git repository is hosted on exherbo.org3. Before going on to tell you about her I want to kindly ask you to help me with some tasks:

  • Proof read the manual page4. I am still unsure about the configuration file format and the magic command API so now is the time to share your ideas and views to help make sydbox-1 better.

  • For brave souls, unmask it and install it. Especially important is to run its tests. To do that you have to set the environment variable PALUDIS_DO_NOTHING_SANDBOXY5. You will notice that it doesn’t depend on pinktrace anymore. This is because sydbox-1 includes a rewrite of pinktrace which will eventually be released as pinktrace-1.

  • Once again for brave souls, use it on your system. I am especially interested in how it performs during the src_test phase of exhereseses so please make sure tests are enabled if you do so and report back any issues (accompanied with a poem of your choosing!). It is always a good idea to have a pbin of the package in question to easily rollback changes in case you hit a severe bug6.

If you are bored, you can stop reading now. I will go on to introduce sydbox-1.

Why?

I am not a professional programmer. However, I have gained many experiences after writing sydbox-0 and watching it perform as the default sandbox of Exherbo. sydbox-0 has many shortcomings and drawbacks which made it rather hard to maintain. Such as:

  • sydbox-0 was based on the now unmaintained catbox initially. There are many design issues which didn’t fit with our use cases for Exherbo.
  • Being GPL-2 licensed it was problematic to share code with the well-established ptrace(2) based projects like strace and truss (of FreeBSD). I have partially solved this problem by writing pinktrace - a BSD3 licensed library providing thin wrappers around certain ptrace(2) calls but this was not enough. (See below about pinktrace-easy)
  • Being a crucial part of the system set, dependencies like GLib was obviously a bad idea.
  • Over the years as sydbox-0 codebase grew there were unforeseen code maintenance problems making it difficult to add new features.

Features of sydbox-1

Below are main features of sydbox-1. You may consult the manual page³ for more information.

  • No external dependencies. GLib dependency is gone for good among with the ini-format configuration file. sydbox-1 uses JSON format for configuration.
  • Most of the ptrace(2) work is now abstracted by a callback-driven higher-level BSD3 licensed library called pinktrace-easy. This makes both the maintenance easier and code sharing with strace less problematic.
  • Well designed, well documented magic command API which fits in with the configuration file format and provides an easier experience during command line invocation.
  • Process dump can be obtained by sending sydbox-1 the SIGUSR1 signal (or SIGUSR2 for a more verbose dump). This makes it easier to debug sydbox hangs.
  • Better signal handling to make sydbox more immune to interrupts.
  • More powerful and configurable rsync-like pattern matching.
  • Support for secure computing mode aka seccomp7. This requires Linux-3.5 or newer and CONFIG_SECCOMP=y and CONFIG_SECCOMP_FILTER=y kernel configuration options. sydbox-scm exheres has a seccomp option to pass --enable-seccomp to econf. This is one of the key features which may make sydbox-1 faster compared to sydbox-0 because in this mode sydbox only traces the sandboxed system calls. Tracing other commonly used system calls - think threaded applications calling sched_yield() - is therefore avoided.
  • Logging is easier to filter. This still needs some work though.
  • Port numbers can now be entered as service names which will be queried from the services(5) database.
  • Unsupported socket families can be whitelisted/blacklisted.
  • New magic commands exec/resume_if_match and exec/kill_if_match are added. These commands may be used to resume or kill matching binaries upon successful execution. Paludis has esandbox resume and esandbox kill commands as an interface for exheres-0 (Make sure esandbox api returns 1 before using them). See systemd.exlib as an example on how we can now restart services from within exhereseses without worrying about sandboxing.
  • Read sandboxing to prevent unwanted filesytem reads.
  • Black listing is now also supported in addition to white listing. This may be used to make an “allow by default and black list unwanted accesses” sandboxing policy.
  • Many bugs fixed, some new system calls are sandboxed.

How can I thank you?

Send me poems8!


  1. She used to be called pandora in the early days.

  2. Not sydbox-0-scm which is the old one.

  3. http://git.exherbo.org/sydbox-1.git/

  4. http://dev.exherbo.org/~alip/sydbox/sydbox.html

  5. Eventually sydbox-1 will install its tests so this phase is going to be more convenient.

  6. sydbox-1 has been tested for some time by kind people and I have heard about only one such issue so far but it is always a good idea to be cautious.

  7. http://lwn.net/Articles/475043/

  8. http://dev.exherbo.org/~alip/sydbox/poems.txt

September 29, 2012 07:00 AM

September 22, 2012

Ciaran McCreesh

Paludis 0.80.0 Released

Paludis 0.80.0 has been released:

  • EAPI 5 is supported.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at September 22, 2012 06:50 PM

September 07, 2012

Ciaran McCreesh

Paludis 0.78.2 Released

Paludis 0.78.2 has been released:

  • Bug fix: || ( ) dependencies under a non-enabled label are now handled sensibly.
  • Bug fix: the resolver no longer attempts to create binaries for accounts.
  • Bug fix: 0-scm is now ordered correctly.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at September 07, 2012 09:02 PM

August 13, 2012

Ciaran McCreesh

Paludis 0.78.1 Released

Paludis 0.78.1 has been released:

  • sydbox-1 is now supported.
  • Bug fix.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at August 13, 2012 10:44 AM

June 08, 2012

Mike Kelly

Encrypting your /home

I was inspired by a post on the Command Line Warriors blog to encrypt my /home directory. Unfortunately, the directions given in that post don't quite work. Here is the process I followed to set everything up.

We're setting up a basic LUKS volume encrypted with AES with a 256-bit key. This means we make a special "filesystem" on the disk partition which encrypts our real filesystem on disk, and makes it available unencrypted via the device-mapper interface (/dev/mapper/).

First, you need to have a partition available for your /home directory. In my case, I decided to nuke my Windows install, but most people will probably need to use parted to resize some existing partitions. If you're resizing your root ("/") partition, you'll need to run it from a LiveCD. For the partition, I chose the "Linux" type, but I'm not sure that really matters.

Once you've allocated the partition, you'll need to create the LUKS partition. You do this with the cryptsetup command. But, before you can use this, you'll need to make sure you've compiled these settings into your kernel: CONFIG_DM_CRYPT, CONFIG_CRYPTO_CBC, CONFIG_CRYPTO_SHA256, and CONFIG_CRYPTO_AES.

After configuring your kernel and you've rebooting, if need be, you'll need to install sys-fs/cryptsetup. Don't install sys-fs/cryptsetup-luks... it's old. The newest (>1.0) versions of cryptsetup are based on the -luks version, and are what you should be using.

Now, use cryptsetup to format the luks partition:


  cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/hda4

Substitute /dev/hda4 with whatever partition you created earlier. It will ask you to enter a password. Use a strong one, and don't just write it on a piece of paper by your computer, or you've defeated the whole point of this.

Now, we need to open the partition so we can create our encrypted data partition. We do this with the following:


  cryptsetup luksOpen /dev/hda4 crypt-home

This will make /dev/mapper/crypt-home, which is the device you use to mount your /home. Currently that partition is unformatted, so use your mkfs of choice to format it.


  mke2fs -j /dev/mapper/crypt-home

Next, make a temporary place to mount this so you can copy over your data, and mount it.


  mkdir /mnt/crypt-home
  mount /dev/mapper/crypt-home /mnt/crypt-home

And then, copy all your data from your current /home to the new one:


  rsync -tarv /home/* /mnt/crypt-home

Now would also be a good time to back up your important data to some other location.

Before we continue, we should configure the system to mount our new /home at boot. This requires editing /etc/fstab:


  # /etc/fstab
  # ... your other stuff ...
  /dev/mapper/crypt-home /home ext3 noatime 0 2

and /etc/conf.d/dmcrypt:


  # /etc/conf.d/dmcrypt
  # This file has all sorts of comments in it already
  # just uncomment the following:

  ## /home with passphrase
  target=crypt-home
  source='/dev/hda4'

Now all that is left is to remove the unencrypted copy of /home. First, you should go through and rm -rf anything that doesn't contain sensitive information, like open source project code, your mp3s, etc.

The last step is to use the shred command to securely delete all the remaining files. Shred works by overwriting a file many times with different patterns to make recovering them extremely difficult. Use the following commands to securely delete all the files in home, and then remove all the empty directories:


  find -H /home/*/ -type f -exec shred -u -v {} \;
  rm -rf /home/*/

Now, reboot and if everything went well, you should be prompted for your password, and then everything should just work as it did before.

Update: fixed links.

by Mike Kelly at June 08, 2012 08:12 PM

Switch to Apache2, WebDAV for Subversion, and evil google robots

So, I finally dropped lighttpd/fcgi and switched back to Apache 2.2. Trac is running with mod_python now. I think I've tracked down the main cause of our load/memory issues - googlebot. It was indexing all 4000 some revisions of our svn repository via the trac browser... bad stuff, but it should be blocked from that by our robots.txt now.

Also, I've added WebDav for Subversion now. Paludis is at http://svn.pioto.org/paludis, and the same is true for most of the other repos I host as well. Now those who have evil company/school firewalls and proxies can get through.

Update: SVN is sooooo 2007. Paludis is using git now: http://git.exherbo.org/paludis/paludis.git/

by Mike Kelly at June 08, 2012 08:07 PM

RbTPB - A ruby script for handling brightness/volume display on thinkpads

So, been a while, but here's something I just threw together. It's still a little rough around the edges, but it seems to be more robust than tpb for my system, at least, and it doesn't require me to make /dev/nvram available.

It uses /sys/class/backlight/thinkpad_screen/actual_brightness (from the thinkpad_acpi module in the 2.6.22 kernel) to figure out the screen brightness, and /proc/acpi/ibm/volume to figure out the volume and mute states, also provided by the thinkpad_acpi module (I'll switch to using sysfs for this when it becomes available).

It also requires the ruby-xosd package, which you can get from my overlay: git://git.pioto.org/pioto-overlay.git

For lazy paludis users, just add this to /etc/paludis/repositories/pioto-overlay.conf:

format = ebuild
location = /var/paludis/repositories/pioto-overlay
sync = git://git.pioto.org/pioto-overlay.git
master_repository = gentoo
names_cache = /var/cache/paludis/names
write_cache = /var/cache/paludis/metadata

Or, you can just do: playman -a pioto-overlay

You can get the current version of this script from git at: https://github.com/pioto/rbtpb

Update: Fix links.
Update 2: Fix links, again.

by Mike Kelly at June 08, 2012 07:55 PM

March 13, 2012

Bryan Østergaard

Pictures from Open Source Days?

This weekend saw yet another edition of the Open Source Days conference in Copenhagen. And despite a few small issues (most notably a large power outage taking out a big area of the city) most people really seemed to enjoy the conference.

I also saw quite a few people taking pictures of the event and we'd love to see those pictures. Please send an email to team2012@opensourcedays.org or directly to me at bryan@opensourcedays.org if you would like to share your pictures.

March 13, 2012 11:47 AM