Search Results: "rul"

16 August 2008

Cyril Brulebois: snapshot.debian.org

Andrew, as already mentioned in the first comment of Eddy s post you re referring to: Ganneff announced that snapshot.d.o will become an official service (ETA: some months). Reference: 20080814211643.GA12330@xanadu.blop.info

15 August 2008

Stefano Zacchiroli: edos-builddebcheck

Statically detecting FTBFS with edos-builddebcheck Here at DebConf8, after my talk about Mancoosi, I got in touch with several people interested in the QA implication of the EDOS/Mancoosi tools. Me and Ralf have for example been contacted by Ubuntu people which are setting up theirs equivalent of http://edos.debian.net. A guy working on a mirroring tool made an interesting hack using edos-debcheck: out of a mirror with broken dependencies he can mirrors a subset of packages which do not suffer of the same problem. But now to the more interesting development, following a bug report by Atomo and discussions with Lucas (the RC-bug-filing-master), me and Ralf implemented edos-builddebcheck. You can invoke it on a pair of Packages/Sources package list, and it will check whether some packages will FTBFS due to unsatisfiable dependencies. The results on Lenny main/amd64 as of today are, ... erm ..., scary : 49 packages will FTBFS. The RC-bug-filing-master and Ralf are working on filing them, "don't worry". You can find edos-builddebcheck in the edos-debcheck package, starting from version 1.0-7 (in incoming at the time of writing). Update yes, ATM edos-builddebcheck does not know anything about P-A-S packages, so there are some false positive. Still, 33 source packages are proper hits.

14 August 2008

Wouter Verhelst: Knife

Yesterday, I was rummaging in my backpack, to make space for a few things I wanted to put in there and that I wanted to take along with me on the daytrip. As I was doing so, I found I'd forgotten to remove a knife from it before leaving for Argentina. Not just any knife, mind you: Knife Yet with this monster in my backpack, I managed to pass security in Brussels International Airport with no issues. At all. Luckily I didn't have to go through security a second time on a different airport, or I might have been in serious trouble. By their own rules, however, they failed. Utterly.

12 August 2008

Lucas Nussbaum: Debian s Freeze

Debian’s freeze sounds like a technical hack to address a social problem, and that disturbs me a bit. The social problem is: At some point, we need everybody in Debian to make only non-disruptive changes, so everything can converge very fast into a releasable state. The “solution” we are using is that we are blocking all packages from migrating to testing, and requiring manual review from someone on the release team. Consequences are:
- many people feel that you need to be very convincing to fix a small, not RC bug, even if fixing that bug definitely increases your package’s quality.
- the release team is completely overwhelmed by unblock requests during the freeze
- many people just stop trying to fix things during the freeze (which definitely doesn’t improve Debian’s quality), both because they think it’s hard to get a fix in, and because they don’t want to bother the release team I wonder if we really need such a strict policy. Are there other Free Software projects that use such a technical measure to prevent software from disrupting stable releases? I am the impression that most other projects rely on social pressure instead of technical measures for that, except maybe during the last few hours before the release. Couldn’t we act on the social level? We could default to allow everyone’s package to migrate to testing, and, when someone fucks up and uploads something that should not have been uploaded, block all his packages (switching to manual review mode) until the release. Of course, that require the release team to make decisions about _people_, which is harder than making decisions about _packages_. But if the rules are clearly stated, couldn’t this work?

11 August 2008

Eddy Petrișor: git-core backport still useless

The versioned depends on tk8.5 has been removed in 1:1.5.6.3-1~bpo40+4, but still, this isn't enough:

$ gitk
/usr/bin/gitk: line 3: /usr/bin/wish8.5: No such file or directory
/usr/bin/gitk: line 3: exec: /usr/bin/wish8.5: cannot execute: No such file or directory


The irony is that you can simply workaround with:

# ln -sf /usr/bin/wish8.4 /usr/bin/wish8.5


But the proper fix would be to apply this patch:


diff --git a/debian/rules b/debian/rules
index 7a1e771..7bd25cd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,7 +7,7 @@ CFLAGS =-g -Wall
STRIP =strip
TEST =test
OPTS =NO_OPENSSL=1 prefix=/usr mandir=/usr/share/man INSTALLDIRS=vendor \
- WITH_P4IMPORT=1 PYTHON_PATH=/usr/bin/python TCLTK_PATH=/usr/bin/wish8.5 \
+ WITH_P4IMPORT=1 PYTHON_PATH=/usr/bin/python TCLTK_PATH=/usr/bin/wish \
THREADED_DELTA_SEARCH=1

ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
--
1.5.6.3

10 August 2008

Joerg Jaspert: DebConf Assassins

Today is the day we start this years Assassins game, and I (together with the two other DebConf admins Mark and Stephen) have the role of the referee. As we all don’t want to do it by hand, and have seen bad examples in the past where the referee just wasn’t up to the task, we go another way. In the last two days, Stephen and me (mostly Stephen) developed a Pentabarf controller to do the work for us. It is ready for the game, so we start today. This controller basically tells the players their target, gets the “I killed em” notice and lets the target confirm it, then assigning a new target. And when we are done with the game - it even tells us the winner and also some information about the other players. This controller made us able to do another change to the known game rules: People can enter the game when it is already running. Which is useful, as now we only let people play that arrived at the venue. Late-comers get added to the players list whenever someone got killed. This ensures that no assassin has to wait for half the Conference time until their target finally arrives! (Ok, it might mean that Late-Comers have to wait a day or two before they finally get a target, as we only insert new players when someone dies). One more note if you are playing: Don’t tell anyone, not even your assassin, your target. Your assassin might not neccessarily get your target as his next (if we add people to the set), so keep it secret, all the time. The only people you should talk to about this game are us 3 admins, but only in case you have a problem. :) Comments: 0

7 August 2008

Russell Coker: A Basic IPVS Configuration

I have just configured IPVS on a Xen server for load balancing between multiple virtual hosts. The benefit is not load balancing but management. With two virtual machines providing a service I can gracefully shut one down for maintenance and have the other take the load. When there are two machines providing a service a load balancing configuration is much better than a hot-spare, one reason is the fact that there may be application scaling issues that prevent one machine with twice the resources from giving as much performance as two smaller machines. Another is the fact that if you have a machine configured but never used there will always be some doubt as to whether it would work… The first thing to do is to assign the IP address of the service to the front-end machine so that other machines on the segment (IE routers) will be able to send data to it. If the address for the service is 10.0.0.5 then the command “ip addr add dev eth0 10.0.0.5/24 broadcast +” will make it a secondary address on the eth0 interface. On a Debian system you would add the line “up ip addr add dev eth0 10.0.0.5/24 broadcast + true” to the appropriate section of /etc/network/interfaces, for a Red Hat system it seems that /etc/rc.local is the best place for it. I expect that it would be possible to merely advertise the IP address via ARP without adding it to the interface, but the ability to ping the IPVS server on the service address seems useful and there seems no benefit in not assigning the address. There are three methods used by IPVS for forwarding packets, gatewaying/routing (the default), IPIP encapsulation (tunneling), and masquerading. The gatewaying/routing method requires the back-end server to respond to requests on the service address. That would mean assigning the address to the back-end server without advertising it via ARP (which seems likely to have some issues for managing the system). The IPIP encapsulation method requires setting up IPIP which seemed like it would be excessively difficult (although maybe not more than required to set up masquerading). The masquerading option (which I initially chose) rewrites the packets to have the IP address of the real server. So for example if the service address is 10.0.0.5 and the back-end server has the address 10.0.1.5 then it will see packets addresses to 10.0.1.5. A benefit of masquerading is that it allows you to use different ports, so for example you could have a non-virtualised mail server listening on port 25 and a back-end server for a virtual service listening on port 26. While there is no practical limit to the number of private IP addresses that you might use it seems easier to manage servers listening on different ports with the same IP address - and there is the issue of server programs that are not written to support binding to an IP address. ipvsadm -A -t 10.0.0.5:25 -s lblc -p
ipvsadm -a -t 10.0.0.5:25 -r 10.0.1.5 -m The above two commands create an IPVS configuration that listens on port 25 of IP address 10.0.0.5 and then masquerades connections to 10.0.1.5 on port 25 (the default is to use the same port). Now the problem is in getting the packets to return via the IPVS server. If the IPVS server happens to be your default gateway then it’s not a problem and it will already be working after the above two commands (if a service is listening on 10.0.1.5 port 25). If the IPVS server is not the default gateway and you have only one IP address on the back-end server then this will require using netfilter to mark the packets and then route based on the packet matching. Marking via netfilter also seems to be the only well documented way of doing similar things. I spent some time working on this and didn’t get it working. However having multiple IP addresses per server is a recommended practice anyway (a back-end interface for communication between servers as well as a front-end interface for public data). ip rule add from 10.0.1.5 table 1
ip route add default via 10.0.0.1 table 1 I use the above two commands to set up a new routing table for the data for the virtual service. The first line causes any packets from 10.0.1.5 to be sent to routing table 1 (I currently have a rough plan to have table numbers match ethernet device numbers, the data in question is going out device eth1). The second line adds a default router to table 1 which sends all packets to 10.0.0.1 (the private IP address of the IPVS server). Then it SHOULD all be working, but in the network that I’m using (RHEL4 DomU and RHEL5 Dom0 and IPVS) it doesn’t. For some reason the data packets from the DomU are not seen as part of the same TCP stream (both in Net Filter connection tracking and by the TCP code in the kernel). So I get an established connection (3 way handshake completed) but no data transfer. The server sends the SMTP greeting repeatedly but nothing is received. At this stage I’m not sure whether there is something missing in my configuration or whether there’s a bug in IPVS. I would be happy to send tcpdump output to anyone who wants to try and figure it out. My next attempt at this was via routing. I removed the “-m” option from the ipvsadm command and added the service IP address to the back-end with the command “ifconfig lo:0 10.0.0.5 netmask 255.255.255.255” and configured the mail server to bind to port 25 on address 10.0.0.5. Success at last! Now I just have to get Piranha working to remove back-end servers from the list when they fail. Update: It’s quite important that when adding a single IP address to device lo:0 you use a netmask of 255.255.255.255. If you use the same netmask as the front-end device (which would seem like a reasonable thing to do) then (with RHEL4 kernels at least) you get proxy ARPs by default. For example you used netmask 255.255.255.0 to add address 10.0.0.5 to device lo:0 then on device eth0 the machine will start answering ARP requests for 10.0.0.6 etc. Havoc then ensues.

6 August 2008

Clint Adams: NM teaches shameful doublespeak for non-free

The worst thing an idealist can be is practical. I see this problem nearly every day when people are trying to comply with laws, rules, regulations, standards, or what-have-you. You fail to meet the objective, so you smudge reality and make compromises. Well, we cannot reasonably drive under the speed limit so let's arbitrarily make up our own limit (10 mph over) and stick to that. That way we endure the hardship of having to comply with something but not the extreme and unattainable hardship of complying with the real thing. Nevermind that some people actually obey the speed limit; that's just anecdotal evidence or a fluke or some other excuse you can use to disregard the fact that what you are claiming is impossible is actually possible. That's an example of a rule mandated by an external power (the oppressor you theoretically owe your allegiance to or the oppressor you are on loan to). Where idealism really comes into play is when people choose their own oppression, be that a formal religion, moral code that they got from a pamphlet somebody was handing out on the sidewalk, or other voluntarily-adopted standards of behavior. Then you end up with raw-food vegans who eat pepperoni pizza twice a week, environmentalists who drive cars, PETA members who keep pets, feminists who are lapsitters, Christians who sin, people who claim that things are best-effort, and people who claim that things that are obviously part of other things are not really part of those things.

5 August 2008

Wouter Verhelst: Re: Government

One of the things of getting too much mail is that you will get swamped in it, sometimes to the level of not even managing to figure out there's been replies on your blog for the past several weeks. Oops. Apparently quite a number of people answered to my blog post about the belgian government issues, and I only found out right before leaving for Argentina. They're now all accepted from moderation, but that doesn't mean I can't follow up on them anymore. Most of them just agree with what I have to say, or posit another opinion (which is fine), but some clearly show a misunderstanding of what I was trying to say. So, since I don't want to appear as one posting gibberish, allow me to clarify:
"I could say that some other things about the past deb cle also puzzle me, such as the insistence of some people to get an unconditional split of BHV, thereby destroying all chances of even remotely reaching a compromise." You are saying that you would accept giving in to the demands of the Francophones that the Flemish give up territory. (Think about it, what century are they from? In what other country does one community demand the enlargement of its territory as an exchange for fixing a situation which the constitutional court has ruled to be illegal?)
Thanks for asking, but no, I'm not saying that. Let's be clear about this: there's a huge difference between a position that says "we need to split BHV, period" on the one hand, and "we need to give territory to the francophone community" on the other. It should be perfectly possible to, say, have the flemish community come up with some benefit to the francophone community in some respect somewhere that does not include "giving territory to the south of france"; but apparently the "negotiators" think not. To quote just one example: at some point Reinders (MR) suggested that a federal election circle be created to replace BHV, so that francophone politicians could still be elected in flanders, but also the other way around. This proposal was however killed by flemish politicians before the press as "not even negotiable" without even having discussed it. This, and other similar examples, I do not understand. After all, the fact that the constitutional court has ruled the current situation to be illegal does not change anything about the fact that this is still a request from the Flemish part of the country, and not from the Francophones; anyone telling you anything else is simply lying. There's nothing wrong with wanting something and being declared correct in court, of course; but there is something wrong with wanting that unconditionally. Unless you won a war, that is. And then still. Of course, not caring about much of the definitions of many political parties and not being a politician in any way, I ticked off someone who just happens to be a member of one of the parties I don't even like in the first place. Amedee, in case it matters: I didn't call CD&V a "Catholic" party to imply anything, but simply because I'm blissfully ignorant of the difference between Catholic and Christian. And happily so, too, given the CD&V's current behaviour. Oh, and the SP.A is not my favourite party; it's just that they seemed to be the more sensible of the lot during the last elections' campaigns. What's really my favourite party isn't something I'll tell you (or anyone), though.

4 August 2008

Marcela Tiznado: When did we start attacking each other?

So, I should be at DebCamp, but I'm back home after driving 800km in one day.  
Why? I still don't know.

The main reason for this post is the irrational and unilateral response I got
from the DebConf Orga Team, with no right to replica of any kind, and with
the violence and humiliation we were treated with. I've helped to make
3 DebConf's possible, and have been involved in many ways for the past years
in Debian, so this shocked me deeply.

The short story is that there was an extra bed in the room I was staying in, the
person who was suppose to be in that bed is a close friend of mine, so I asked
if someone else could use it while they weren't, since that meant I could take
the necessary equipment that I managed to get for DebConf, and also introduce
to Debian someone who is very active and well known in our local community
(and also part of the umbrella foundation used for local finance issues).
I was excited about getting there, like every year. Just to make this extra
clear, this person had already booked the full week of DebConf, just not
DebCamp, as he previously thought he couldn't attend. When he found out he
could, he was thrilled to be able to go and help setup. So, I made the mistake
of not notifying the Orga team about the switch. I did this because it truly
was harmless action, where a bed which would otherwise be wasted would get
used, and, I did not notify the Orga team because they've been very
aggressive, inflexible and unhelpful throughout the planning of the
conference. This doesn't justify it, just explains why someone who generally
is helpful decides to take the wrong path to solve something.

Up to here, nothing very exciting. What made this special, is that when one
of the organizers, Margarita Manterola, found out about the switch, instead
of coming to talk to me, even though she's known me for *years*, she went
and informed the hotel that somebody had committed a crime, and checked in
under a different name, as if me or the person that came with me where
some random stranger. All I can say is, WTF?

Let me stress this, the email that was sent out[1] twisted the facts, to the
extent that some of them are a lie, like the problem arrived at check-in,
when it actually happened while we where napping a few hours after we had
arrived, and any effort made by the Orga team with the hotel where wasted,
as it was one of them who had originally created the problem.

Instead of solving this among us as a group, and, again, "solve" is a
bureaucratic thing, because no one was being harmed, Marga decided to
actually *harm* me personally, the person who I had brought, and DebConf
as a group. What got solved? Nothing. I left, along with someone who
would of otherwise been helping out build DebConf, while the Orga team
demanded a ridiculous fee for me to stay in the hotel.
Rules are rules, I understand, but I also understand everybody listens to
downloaded music, people in Germany install[2] nmap, and a very long list
of rules that we tend not to follow because they're unreasonable or
unnecessarily complicated.
Is this really what DebConf is turning into?

All I can say is I'm very sad and shocked that the people I've worked with
for so many years decided to condemn me over such a meaningless issue, and
especially that the local team, Martin Ferrari, Damian Viano, Maximiliano
Curia and Margarita Manterola would do such thing to "one of there own",
and that the international Orga team would mindlessly follow through with it.

I apologized to the hotel, I do want to apologize to the innocent people who
had to deal with this, and, even though my intentions where good and unselfish,
I regret what happened.

Despite all of this, I'm still deeply committed to Debian, have worked during
the year and deserve to relax and enjoy it, so I will be there for DebConf
as a regular attendee.

See you there!

[1] http://lists.debconf.org/lurker/message/20080802.231856.66c7d3fd.en.html
[2] http://it.slashdot.org/article.pl?sid=07/05/31/1629259&from=rss

3 August 2008

Sandro Tosi: Minimal debian/rules for dh7+dpatch

I got a new package to start from scratch (amule-emc, ITP) so I wanted to try debhelper 7. In need of patching upstream source code, I used my old friend dpatch, but then started to have some problems putting things together; so, here below is the minimal debian/rules to use dh7+dpatch:

#!/usr/bin/make -f
include /usr/share/dpatch/dpatch.make

build: build-stamp
build-stamp: patch-stamp
dh build
touch $@

clean:
dh clean

%:
dh $@

Thanks to jcristau and noshadow from #debian-devel@OFTC for opening my eyes ;)Edited: thanks to Joey's comment, I was able to reduce it again down to:

#!/usr/bin/make -f

include /usr/share/dpatch/dpatch.make

build: patch-stamp
dh build

clean: unpatch
dh clean

%:
dh $@

1 August 2008

Russell Coker: Upgrading SE Linux Policy

When I first packaged the SE Linux policy for Debian the only way to adjust the policy was to edit the source files and recompile. Often changes that you might desire involved changing macros so while it would have been theoretically possible to just tack a few type definitions and allow rules at the end, you often wanted to change a macro to have a change apply all through the policy. To deal with that I had the policy source installed on all machines and the package update policy would compile it into a binary form and load it into the kernel. Now there was the issue of merging user changes with changes from a new policy package. For most configuration files on a Unix system you can just leave any files that are modified by the user, not taking the new default configuration might cause the user to miss out on some new features - but presumably they were happy with the way it worked in the past. However due to inter-dependencies this wasn’t possible for SE Linux, if one file was not ungraded due to user changes and other files related to it were then the result could be a compile failure. Another issue was the fact that a newer version of the policy might permit operations that the sys-admin did not desire and therefore not meet their security goals, or it might not permit operations that are essential to the operation of the system and interrupt service. To solve this I wrote a script that prompted for upgrades to policy source files and allowed the sys-admin to choose which files to upgrade. This worked reasonably well in the early days when the number of files was small. But as the policy increased in size it became increasingly painful to upgrade the policy with as many as 100 questions being asked. The solution to this (as implemented in Fedora Core 5, Debian/Etch, and newer distributions) was to have binary policy modules that maintain their dependencies. Now there are binary policy modules which can be loaded at will (the default install for Debian only installs modules that match the installed programs) and the modules can have optional sections with dependencies. So if you remove a module that defines a domain and there are other modules which have rules to allow communication with that domain then the optional sections of policy in the other modules is disabled when the domain becomes undefined. This solves the technical issues related to module inter-dependencies but the issue of intent and interaction with the rest of the system remains. With Red Hat distributions the solution has been to upgrade the running policy every time the policy package is upgraded and be cautious when changing policy. They do a good job of the upgrade process (including relabeling files when the file contexts change) and in terms of policy changes I have not heard complaints from users about that. Users who don’t want a newer version of the policy can always put the package on hold. For the Debian distribution after Lenny I plan to have a policy upgrade process that relabels files and a debconf question as to whether package upgrades should upgrade the policy. But for Lenny the freeze is already in progress so it seems to late to make such changes. Instead I’m going to upload a new version of the selinux-basics package with a program named selinux-policy-upgrade that will upgrade all the policy modules that are in use. This is not the ideal solution, but I think it will keep Lenny users reasonably happy.

Erich Schubert: New pyroman release

As mentioned earlier, I've uploaded a new Pyroman release to Debian. I've also updated the download at the download page on alioth for the non-Debian users.There is just one single user-visible change (under the hood I switched some Python API so you need python 2.4+ now, which was available in sarge already):This version has a new command line option, "--verification-cmd". This can be used to point to a script file to verify network connectivity. For example, you could try to send a ping to the next router, or you could ssh to another host, have it ssh back and touch a flag file in /tmp to signal success.Similar to the --safe option, it is meant as a safety feature to avoid locking yourself out of your system. But while --safe needs to be used interactively, this new command could be used when automatically activating new firewall rules, e.g. triggered by cfengine or some other configuration management. If the verification command does not succeed, the firewall rules will automatically be rolled back to the previous state.Note that I didn't get around to add IPv6 support yet. It would definitely be desirable to add ip6tables support, but I currently do not have any experience with IPv6, so I'm not sure I'd know how to do things right. Of course I'd welcome any patches.(In case you havn't read about pyroman yet - it's yet another tool to configure iptables firewalls. It puts a thin abstraction layer on top of iptables, but the main benefit is that it uses "iptables-restore" to quickly mass-set all the firewall rules - other tools tend to invoke several hundred iptables processes to achieve the same - and if any error occurs it will both give you a clear indication of which rule caused the error and rolling back your firewall to the previous state.)

30 July 2008

Steve Kemp: I know how to make a Holy Bartender

I've made a new release of my sift IMAP utility, which now adds a few new types of rules:
  • Match message bodies against regular expressions.
  • Match recipients against regular expressions.
All the "searching" rules now allow negation too, so that "from:foo@bar.com" and "!from:foo@bar" work as you'd expect. Finally each of the searching rules, which require the download of the complete IMAP message, will use a local disk-cache to avoid undue overhead. All in all I'm pretty pleased with the way the tool is being used in the wild. Each of these changes were the result of a direct user request, or suggestion. ObMovie: Dogma

24 July 2008

Russell Coker: SE Linux Policy Loading

One of the most significant tasks performed by a SE Linux system is loading the “policy“. The policy is the set of rules which determine what actions are permitted by each domain. When I first started using SE Linux (in 2001) the kernel knew where to find the policy file and would just read the data from disk as soon as it had mounted the root filesystem. Doing such things is generally considered to be a bad idea, but it was an acceptable mechanism for an early release. One issue is that the policy needs to be loaded very early in the system boot process, before anything significant happens. In the early days the design of SE Linux had no support for a process to change it’s security context other than by executing another process (similar to the way a non-root process in the Unix access control system can not change it’s UID, GID, or groups). Although later on support for this was added, it was only available as the request of the application (an external process could not change the context of an application without using ptrace - a concept that is too horrible to contemplate) and I am not aware of anyone actually using it. So it’s almost a requirement that there be no more than one active process in the system at the time that policy is loaded, therefore it must be init or something before init that loads the policy. When it was decided that a user-space program had to instruct the kernel to load the policy we had to determine which program should do it and when it should be done, with the constraint that it had to be done early. The most obvious solution to this problem was to load the policy in the initramfs (or initrd as it was known at the time). One problem with this is that the initramfs is limited in size by kernel compilation options and may need to be recompiled to fit a bigger policy. As an experiment to work around this limitation I had a small policy (which covered the domains for init and the scripts needed for the early stages for system boot) loaded in the initramfs and then later in the boot process (some time after the root filesystem was mounted read/write) the full policy was loaded. A more serious problem with including policy in the initramfs was that it required rebuilding the initramfs every time the policy changed in a significant way, of course scripts could not determine when a change was significant (neither could most users) so that required needless rebuilds (which wastes time). Even with a small policy for early booting loaded it was still sometimes necessary to change it and update the initramfs. I believe that as a general rule an initramfs should only be rebuilt when a new kernel is installed or when a radical change is made to the boot process (EG moving from single disk to software RAID, changing between AMD and Intel CPU architecture, changing SCSI controller, or anything else that would make the old initramfs not boot the machine). The initramfs that was used to boot my machine is known to actually work, the same can not be said for any new initramfs that I might generate. But the deciding factor for me was support of machines that did not use an initramfs or initrd (such as the Cobalt machines [1] I own). To solve these problems I first experimented with a wrapper for init. The idea was to divert the real init to another file name (or use the init= kernel command-line option) and then have the wrapper load the policy before running the real init. I never intended that to be a real solution, just to demonstrate a point. Once I had proven that it was possible to load the policy from user-space before running the real init program it was a small step to patch init to do this. One slightly tricky aspect of this was in getting the correct security context for init. The policy has always been written to allow a domain transition from kernel_t to init_t when a file of type init_exec_t is executed. The domain kernel_t is applied to all active processes (including kernel threads) at the time the policy is loaded. So init only has to re-exec itself to get the correct context. Fortunately init is designed to do this in the case of an upgrade so this was easy to manage. Since that time every implementation of SE Linux apart from some embedded systems has used init to load the policy. The latest trend in Linux distributions seems to be using upstart [2] as a replacement for the old SysV Init. The Fedora developers decided to make nash (a program that comes from the mkinitrd source tree in Fedora and is a utility program for a Red Hat based initramfs) load the SE Linux policy as it would apparently be painful to patch every init to load the policy. As far as I am aware there are only three different init programs in common use in Linux, the old SysV Init (which used to be used by everyone), Busybox (for rescuing broken systems and for embedded systems), and now Upstart (used by Ubuntu and Red Hat since Fedora 9). Embedded systems need to work differently to other systems in many ways (having the one Busybox program supply the equivalent to most coreutils in one binary is actually a small difference compared to the other things), and modifying the policy load process for embedded systems is trivial compared to all the other SE Linux work needed to get an embedded system working well. There are at least two commonly used initramfs systems (the Debian and Red Hat ones) and probably others. As one init system (SysV Init) already has SE Linux support it seems that only one needs to be patched to have complete coverage. I’ve just written a patch for Upstart (based on the version in Debian/Experimental) and sent it to an Ubuntu developer who’s interested in such things. I also volunteer to patch any other init system that is included in Debian (I am aware of minit and will patch it as soon as it’s description does not include “this package is experimental and not easy to install and use“). It seems to me that repeating the work which was done for SysV Init and upstart for any other init system will be little effort, at worst no greater than patching an initramfs systems (and I’ll do it). As the number of initramfs systems that would need to be patched would exceed the number of init systems it seems that less work is involved in patching the init systems. The amount of RAM required by the initramfs is in some situations a limitation on the use of a system, when I recently did some tests on swap performance by reducing the amount of RAM available to a Xen DomU [3] it was the initramfs that limited how small I could go. So adding extra code to the initramfs is not desired. While this will be a small amount of code in some situations (when I patched /sbin/init from Upstart it took an extra 64 bytes of disk space on AMD64), dragging in the libraries can take a moderate amount of space (the fact that an LVM or encrypted root filesystem causes SE Linux libraries to be included in the initramfs is something that I consider to be a bug and plan to fix). Finally not all boot loaders support an initrd or initramfs. I believe that any decision which prevents using such sweet hardware as Cobalt Qube and Raq machines from being used with SE Linux is a mistake. I have both Qube and Raq machines running fine with Debian SE Linux and plan to continue making sure that Debian will support SE Linux on such hardware (and anything with similar features and limitations).

23 July 2008

Gunnar Wolf: Virtually having fun

Several weeks ago, the people in charge of maintaining the Windows machines in my institute were desperate because of a series of virus outbreaks - Specially, as expected, in the public lab - but the whole network smell virulent. After seeing their desperation, I asked Rolman to help me come up with a solution. He suggested me to try replacing the Windows workstations by substituting local installations by a server having several virtual machines, all regenerated from a clean image every day, and exporting rdesktop sessions. He suggested using Xen for this, as it is the virtualization/paravirtualization solution until now best offered and supported by most Linux distributions (including, of course, RedHat, towards which he is biased, and Debian, towards I am... more than biased, even bent). So far, no hassle, right?
Of course, I could just stay clear of this mess, as everything related to Windows is off my hands... But in October, we will be renewing ~150 antivirus licences. I want to save that money by giving a better solution, even if part of that money gets translated to a big server.
Get the hardware
But problems soon arose. The first issue was hardware. Xen can act in its paravirtualization mode on basically any x86 machine - but it requires a patched guest kernel. That means, I can paravitualize many several different free OSs on just any computer I lay my hands on here, but Windows requires full- or hardware-assisted- virtualization. And, of course, only one of the over 300 computers we have (around 100 of which are recent enough for me to expect to be usable as a proof-of-concept for this) has a CPU with VT extensions - And I'm not going to de-comission my firewall to become a test server! ;-)
When software gets confused for hardware
So, I requested a Intel Core 2 Quad Q9300 CPU, which I could just drop in any box with a fitting motherboard. But, of course, I'm not the only person requiring computer-related stuff. So, after pestering the people in charge for buying stuff on a daily basis for three weeks, the head of acquisitions came smiling to my office with a little box in his hands.
But no, it was not my Core 2 Quad CPU.
It was a box containing... Microsoft Visio. Yes, they spent their effort looking for the wrong computer-related thingy :-/ And meanwhile, Debconf 8 is getting nearer and nearer. Why does that matter? Because I have a deadline: By October, I want the institute to decide not to buy 150 antivirus licenses! Debconf will take some time off that target from me.
Anyway... The university vacations started on July 5. The first week of vacations I went to sweat my ass off at Monterrey, by Monday 14 I came back to my office, and that same day I finally got the box, together with two 2GB DIMMs.
Experiences with a nice looking potential disaster
Anyway, by Tuesday I got the CPU running, and a regular Debian install in place. A very nice workhorse: 5GB RAM, quad core CPU at 2.5GHz, 6MB cache (which seems to be split in two 3MB banks, each for two cores - but that's pure speculation from me). I installed Lenny (Debian testing), which is very soon going to freeze and by the time this becomes a production server will be very close to being a stable release, and I wanted to take advantage of the newest Xen administration tools. Of course, the installation was for AMD64 - Because 64 bitness is a terrible thing to waste.
But I started playing with Xen - And all kind of disasters stroke. First, although there is a Xen-enabled 2.6.25 Linux kernel, it is -686 only (i.e. no 64 bit support). Ok, install a second system on a second partition. Oh, but this kernel is only domU-able (this is, it will correctly run in a Xen paravirtualized host), but not dom0-able (it cannot act as a root domain). Grmbl.
So, get Etch's 2.6.18 AMD64 Xen-enabled kernel, and hope for the best. After all, up to this point, I was basically aware of many of the facts I mentioned (i.e. up to this point I did reinstall once, but not three times)... And I hoped the kernel team would have good news regarding a forward-port of the Xen dom0 patches to 2.6.25 - because losing dom0 support was IMO a big regression.
But quite on time, this revealing thread came up on the debian-devel mailing list. In short: Xen is a disaster. The Xen developers have done their work quite far away from the kernel developers, and the last decent synchronization that was made was in 2.6.18, over two years ago. Not surprisingly, enterprise-editions of other Linux distributions also ship that kernel version. There are some forward-patches, but current support in Xen is... Lacking, to say the least. From my POV, Xen's future in the Linux kernel looks bleakish.
Now, on the lightweight side...
Xen is also a bit too complicated - Of course, its role is also complicated as well, and it has a great deal of tunability. But I decided to keep a clean Lenny AMD64 install, and give KVM, the Kernel Virtual Machine a go. My first gripe? What a bad choice of name. Not only Google searches for KVM gives completely unrelated answers (to a name that's already well known, even in the same context, even in the same community).
KVM takes a much, much simpler approach to virtualization (both para- and full-): We don't need no stinkin' hypervisors. The kernel can just do that task. And then, kvm becomes just another almost-regular process. How nice!
In fact, KVM borrows so very much from qemu that it even refers to qemu's manpage for everything but two command-line switches.
Qemu is a completely different project, which gets to a very similar place but from the other extreme - Qemu started off as Bochs, a very slow but very useful multi-architecture emulator. Qemu started adding all kinds of optimizations, and it is nearly useful (i.e. I use it in my desktop whenever I need a W2K machine).
Instead of a heavyweight framework... KVM is just a modprobe away - Just ask Linux to modprobe kvm, and kvm -hda /path/to/your/hd/image gets you a working machine.
Anyway - I was immediatly happy with KVM. It took me a week to get a whole "lab" of 15 virtual computers (256MB RAM works surprisingly well for a regular XP install!) configured to start at boot time off a single master image over qcow images.
KVM's shortcomings
Xen has already been a long time in the enterprise, and has a nice suite of administrative tools. While Xen depends on having a configuration file for each host, KVM expects them to be passed at the command line. To get a bird-eye view of the system, xen has a load of utilities - KVM does not. And although RedHat's virt-manager is said to support KVM and qemu virtualization (besides its native Xen, of course), it falls short of what I need (i.e. it relies on a configuration file... which lacks expresivity to specify a snapshot-based HD image).
To my surprise, KVM has attained much of Xen's most amazing capabilities, such as the live migration. And although it's easier to just use fully virtualized devices (i.e. to use an emulation of the RTL8139 network card), as they require no drivers extraneous to the operating system, performance can be greatly enhanced by using the VirtIO devices. KVM is quickly evolving, and I predict it will largely overtake Xen's (and of course, vmware and others) places.
Where I am now
So... Well, those of us that adopt KVM and want to get it into production now will have some work of building the tools to gracefully manage and report it, it seems. I won't be touching much my setup until after Debconf, but so far I've done some work over Freddie Cash's kvmctl script. I'm submitting him some patches to make his script (IMHO) more reliable and automatizable (if you are interested, you can get my current version of the script as well). And... Starting September, I expect to start working on a control interface able to cover my other needs (such as distributing configuration to the terminals-to-be, or centrally managing the configurations).

20 July 2008

Russell Coker: Review of the EeePC 701

I have just bought a EeePC 701 [1], I chose the old model because it’s significantly smaller than the 90x series and a bit lighter too and it had Linux pre-loaded. Also it was going cheap, while I am not paying for it I give the same attention to saving my clients’ money as to saving my own. I ruled out everything that was heavier or larger than an EeePC 901 and everything that cost more than $700. That left only the Linux version of the EeePC 901 (which I couldn’t find on sale) and the EeePC 701 as my options. I also excluded the EeePC 900 because it is bigger and heavier than the 701 but has the same CPU (and therefore can’t run Xen). In terms of it’s prime purpose (a SSH client) 96*22 characters is the size of a konsole screen with the default (medium) font size when the window is maximised, that is 5% more characters than the standard terminal size of 80*25 but the smaller number of lines is a problem. When using the small font I can get 129*29 which I find quite comfortable to read (it would be impossible for me to read withut glasses - which means having almost average vision for someone in their 30’s). Then I can get 129*31 if I dismiss the tool bar at the bottom of the screen and could probably get another couple of rows if I removed the tabs that Konsole uses to switch between sessions. That would only be viable if using screen extensively as a single session without the ability to switch between programs is not particularly useful (I don’t think that ALT-TAB is adequate for switching between terminal sessions). When running Debian I can get 130*32 with the same font due to smaller window controls, but I’ll write more about converting to Debian in another post. Note that while the OS that ships with the Linux based EeePC machines is based on Debian, it is heavily customised and has some notable differences from a typical Debian install. It has some proprietary software, and uses unionfs for the root and /home filesystems. The first issue is that Console (the KDE terminal program) can only be accessed from the file manager (via the tools menu or ^t), the machine clearly doesn’t have defaults for someone like me. In principle it’s a multi-user system that can be fully customised, but in practice it’s configured as a single-user machine. Once you have a Console window open you can run “su -” and the root password is the password for the “user” account. I wonder whether I could get more than 42 rows or more than 140 columns of text that is readable. If so then I could have two console windows fully displayed on screen. The screen is bright and clear, this is essential as the number of pixels per character is going to be low for any reasonable amount of text to be displayed on screen. The password that you set when you first use the machine also works for “su -” (in fact that is the only real use as I expect that almost everyone will choose the automatic login option). The display comprises a significant portion of the weight, if the screen is fully open (about 150 degrees) then it will tip over. Even when the screen is not as far open it will tip due to bumps if resting on your lap on a tram. It’s a pity that the screen is connected at the very back of the base, if the attachment point was a bit closer then it would balance better and also be easy to hold with one hand. The depth of the machine combined with the angle at the back makes it impossible for me to get a good one-handed grip from the base, so typing while standing on a moving tram or bus will be extremely difficult (unlike my iPaQ which I can use at full speed on any form of public transport). Inidentally it would be good if there was an attachment point for a wrist-strap, every camera and most mobile phones have them so it would be good to have the same safety feature in a laptop to facilitate use on public transport. Another reason for not using it as a PDA is the fact that it takes about 7 seconds to resume after hibernating (when the lid is closed). The PSU is almost as small as that of a mobile phone! This is a major benefit as in the past I have often stored a Thinkpad PSU at a client site for 9-5 jobs as it is heavy enough that I didn’t want to carry it on public transport. The EeePC PSU is light enough that it won’t be unpleasant to carry, and small enough to fit easily into a jacket pocket. The OS installation is very well done for the basics. It’s easy to launch applications and there is a good selection of educational programs (including the periodic table, planetarium, typing, letters, and hangman, drawing, and a link to www.skoool.com). It’s a pity that they organised the folders according to the area rather than the age, but generally the OS is very well done. Most of the reviews focus on the speed of the CPU, the RAM expansion options, etc, but miss the fact that it is a really nice machine for using as-is. It is a much better machine for teaching children than any of the machines I’ve seen which are sold specifically for children (see my previous post about an awful computer for kids [2]). I believe that you could give an EeePC to any 3yo and have them doing something useful in a matter of minutes! The ability to freely install new software should not be overlooked when considering a computer for children to use. Someone who buys one now could use it for a few years as an ssh client and then reinstall the original OS and give it to a child as an educational toy. It has a program to create OGG video files from it’s built-in camera and mic, at this moment it’s the only device I own that can create OGG files (this is a good thing). OGG compression takes a really long time, the Atom CPU in the 901 and 1000x series would be good for this. It’s a pity that the microphone is directly below the mouse buttons, it clearly records the mouse click used to finish recording. The version of mplayer which is installed to play OGG files can also play FLV files downloaded from youtube with youtube-dl (althrough the file association is not set). When I tried to play a MP4 file from ted.com it only gave audio (the video works on a full Debian/Etch installation). There is a full set of office software, OpenOffice.org, Thunderbird email client, and all the other stuff you might expect. I find that the biggest problem for using it is the size of the keyboard, I don’t think I’ll ever be able to touch-type properly on it. Not only are the keys small but the positions of non-alphabetical keys are slightly different from most keyboards. Another problem is that the space-bar needs to be pressed near the centre, I usually like to press near the end but that doesn’t work. Those issues are all trade-offs of the small size. My T series Thinkpad is reasonably portable and has a great keyboard so I have the serious typing while travelling angle covered. One real mistake in the keyboard design is the lack of a LED to indicate whether caps-lock is enabled (there are four status LEDs, adding number five couldn’t be that expensive), this is a real problem when using the vi editor (which uses letters as editor commands and is case-sensitive). It will also occasionally cause problems when entering passwords. There is a caps-lock indicator on screen, but that is in the toolbar at the bottom of the scren (which I like to dismiss to gain an extra two lines of text). It would be good if I could display the status of the caps and num lock keys in the right side of the title-bar of the active window (the only bit of unused space on the screen). The cooling fan makes an annoying buzz. It’s significantly louder than Thinkpads which dissipate a lot more heat. The other problems are all software, which is OK as I plan to reinstall it. Firstly it is using Debian and shipped with the broken openssl library. There is a GUI for installing upgrades, but it recommends rebooting after installing each one! Naturally I didn’t choose to reboot, I installed the security update #1. Then I clicked on the button to install a BIOS update. It told me that it had to reboot to apply the update and gave only one button (OK), I tried closing the window but it rebooted anyway (fortunately the vi swap file allowed me to recover this post - which I am entirely writing on the EeePC). Aftere booting up again I discovered that the libssl bug still wasn’t fixed and that there was a second udate to apply! Why can’t they have a “apply all updates” button and also have it not automatically reboot? This must be the only Debian-based distribution that forces Windows-style reboots. But that said, while they made some mistakes in their software it generally provides a good user experience

19 July 2008

Luciano Bello: Exploiting DSA-1571: How to break PFS in SSL with EDH

( I love acronyms :-D )

At this point, all of you should know and see how the H D Moore s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).
Introduction to EDHLet s put it in plain words (if you know what we are talking about, ignore this and jump to the next heading):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):
  • The server selects a random prime p and a generator g of the field Z*p (Let s ignore the mathematical properties of these values). So, the components p and g are public.
  • The server picks a secret random number Xs and calculates Ys=gXs mod p. Ys is public and is sent to the client (just like p and g).
  • The client does something similar, selecting a secret random number Xc and calculating Yc=gXc mod p too. The client makes Yc public by sending it to the server.
  • The shared secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=YsXcmod p and for the server s=YcXsmod p.
  • With this shared secret the parties can encrypt all the following messages in a secure way.
  • In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematically secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.
The exploit If an eavesdropper can explore the complete private key space (the all possible numbers for Xc or Xs), he/she will be able to get access to the shared secret. With it all the communication can be deciphered. That s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.


  • The patch for Wireshark 1.0.2 can be downloaded from here.
  • Debian packages with the patch applied can be found here.
  • This is a list of all 215 possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
  • An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD= getpid.so ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )
The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.
Issues that can be improvedWe (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, if you want to contribute with some code, start from these items and submit the patches to the Wireshark s bugzilla:
  • When the packets are out-of-order the decipher with stop itself.
  • The brute force attack should run in a background process (and with a progress bar)
  • Check the length of the keys before trying to brute force them.
  • The patch also implements the display of public DH parameters in the packet tree. It s incomplete.
CreditsPaolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

UPDATE Jul. 21st: See more and updated info here, especially this.

Luciano Bello: Exploiting DSA-1571: How to break PFS in SSL with EDH

( I love acronyms :-D )

At this point, all of you should know and see how the H D Moore s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).
Introduction to EDHLet s put it in plain words (if you know what we are talking about, ignore this and jump to the next tittle):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):
  • The server selects a random prime p and a generator g of the field Z*p (Let s ignore the mathematical properties of these values). So, the components p and g are public.
  • The server picks a secret random number Xs and calculates Ys=gXs mod p. Ys is public and is sent to the client (just like p and g).
  • The client does something similar, selecting a secret random number Xc and calculating Yc=gXc mod p too. The clients makes Yc public by sending it to the server.
  • The share secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=YsXcmod p and for the server s=YcXsmod p.
  • With this share secret the parties can encrypt all the following messages in a secure way.
  • In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematicaly secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.
The exploit If an eavesdropper can explore the complete private key space (the all possible numbers for Xc or Xs), he/she will be able to get access to the share secret. With it all the communication can be deciphered. That s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.


  • The patch can be downloaded from here.
  • Debian packages with the patch applied can be found here.
  • This is a list of all 215 possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
  • An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD= getpid.so ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )
The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.
Issues that can be improvedWe (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, If you want to contribute with some code, start from these items and submit the patches to the Wireshark s bugzilla:
  • When the packets are out-of-order the decypher with stop itselft.
  • The brute force attack should run in a background process (and with a progression bar)
  • Check the length of the keys before trying to brute force them.
  • The patch also implements the display of public DH parameters in the packet tree. It s incomplete.
CreditsPaolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

17 July 2008

Stefano Zacchiroli: paper about mancoosi at debconf8

Mancoosi paper for DebConf8 now available As previously announced, I'll be attending DebConf this year, as I did for the past 3 years. Beside the usual projects and ideas one carries with himself on his way to a DebConf, this time I will also be there to present part of my everyday work in the Mancoosi project. Very briefly (and a bit too simplistic) Mancoosi is working on pushing forward the research and technology needed to deliver better package managers to the users of open source software distributions. The project presentation event proposed by me and Ralf Treinen has been accepted in the DebConf main track. The presentation will discuss what the former EDOS project did, what Mancoosi is doing right now, trying to focus on their relationships with Debian. In case you are interested I suggest to attend the talk which will be delivered by yours truly (what else can I suggest? :) ) In the meantime, the accompanying paper is now available, you can take a sneak peek if you are interested in knowing more about Mancoosi right ahead. The paper is available in .pdf format from both my homepage and from the Pentabarf event page as an attachment (the latter, as all Pentabarf events, needs login for reasons that I still fail to understand ...). Download
  • paper (PDF format, 316 Kb)

Next.

Previous.