Yesterday I visited the MySQL Customer Conference in Munich. First of all, GDL sucks. But the locomotive driver strike was the only negative issue on that day, the conference itself was quite good, especially Jan Kneschke's talk about MySQL performance tuning (which was mostly about combining MySQL Cluster and MySQL Proxy) and the panel discussion about storage engines with Ralf Gebhardt, Jan Kneschke and Kai Voigt as vocal and Kaj Arn as moderator. All in all a great (but quite long and exhausting) day.

We went to see Sarah's cardiologist the week after she was discharged from hospital, and he said that looking back over all of the echocardiograms that have been taken in the 18 months or so that he's been following her, it looks like her aortic aneurysm has gotten a little bit bigger. It's still below the size that they'd normally operate at, but he said that in his opinion it should be repaired before attempting another pregnancy, to play it safe. He even said that afterwards, Sarah could go back to doing triathlons, which is a big step back towards a normal life. So on Monday, we had an appointment with Dr Craig Miller, who is apparently the best cardiac surgeon in the US, and one of the top three in the world, when it comes to aortic aneurysm repair whilst being able to save the heart valve. We'd done a heap of reading up on Dr Miller before the appointment, and the cardiologist's clinic administrator had told us about him as well. Apparently he's a real character. He certainly looked it from the staff photo (linked above). In reality he looked much more like this. But he's certainly a real cowboy type. We saw his nurse practitioner on Monday before we saw him, and his nurse practitioner was this moderately pierced, cowboy boot wearing, "y'all" speaking kinda guy, who really knew his stuff. In fact we exhausted all of our questions that we had for Dr Miller on him before we even saw Dr Miller, because he was running a bit late with the previous patient. This is where Sarah's got a pretty detailed write-up of what they're planning on doing. They're going to replace more of the aorta than they would otherwise (because the enlargement seems to be continuing further up the aorta), which makes the surgery a little more involved, in that they're messing with the arteries that lead up to the brain, so they've got to some more funky bypass work, and lower her core temperature so her brain copes with the blood flow being monkeyed with. Dr Miller was very softly spoken, and a lot older looking than I'd expected, given the whole cowboy hat thing. He seemed really nice and thorough, and explained everything. He also showed us what a mechanical valve looked like. The reason sparing the valve is so important is that the alternatives if they can't are either a pig's heart valve or a mechanical one. Both have their drawbacks. A pig's valve won't last the rest of Sarah's life. She'd need to have valve replacement surgery at some point down the track (I think they said about 8 years, although they wear out faster in younger people). A mechanical valve requires you to take blood thinning drugs for the rest of your life. One of the side effects of these drugs are birth defects. It's also audible from outside the body. We got to see (and keep) a sample of the Dacron tubing that they use to replace the part of the aorta they're removing. I was totally taken aback by the diameter of it. I hadn't sat down and really thought about what 4.4cm (which is about what her aneurysm is currently at) really looked like. The operation is likely to take 8 to 10 hours. I'm not looking forward to that waiting game. Dr Miller said the procedure, whilst sounding pretty bloody scary has about a 1% risk. I'm not exactly sure what that is a risk of though. Sarah's booked in for January 3 next year. The road ahead is still long.

SELinux is entirely correct about disallowing dynamic code generation, as it is a major security risk. Disregarding Just-In-Time compilation, the main legitimate need for dynamic code generation is to support (downward) closures that are ABI-compatible with normal C functions. GCC’s local functions extension of C is one example, and many non-C languages need them badly in their foreign-function interfaces (Haskell is one, Ada I’m told is another). A closure is a function pointer that refers to a function that is local to another function. That function has access to the local variables of the parent function, and this access is provided by having the caller give the callee a static link (a pointer to the parent function’s stack frame) as a hidden parameter. If the call is direct (that is, not through a function pointer), the caller knows the appropriate static link and can just pass it. The trouble comes with function pointers, as we need some way of including the static link in the function pointer. The simplest way is to have function pointers be two words long; one of the words contains the classical function pointer (that is, the entry point address), and the other contains the static link. Unfortunately, the prevalent C ABIs, including the SYSV ABI used by GNU/Linux, mandate that function pointers are one word long. The only way I know to work around this is to dynamically generate, when the function pointer is created, a small snippet of code that loads the correct static link to the appropriate place and jumps to the actual code of the function, and use the address of this snippet (usually called a trampoline) as the function pointer. The snippet is generated on the stack or in the heap, and thus requires an executable stack or executable dynamic memory. It’s time to fix the ABI to allow for proper two-word function pointers.

In a comment on my previous post about SE Linux and worms/trojans [1] a user enquired about which methods of gaining local root are prevented by SE Linux. A local exploit is one that can not be run remotely. An attack via TCP or UDP is generally considered a remote exploit - even though in some cases you might configure a daemon to only bind to localhost (in which case the TCP or UDP attack would only work locally). When compromising a machine it’s not uncommon for a local exploit to be used after a remote exploit or social engineering has been used to gain non-root privileges. The two most common types of local root exploit seem to be those which attack the kernel and those which attack a SETUID process. For a non-SE Linux system it usually doesn’t matter much how the local exploit is run. But a SE Linux system in a default configuration will be running the Targeted policy that has almost no restrictions on a user shell session. So an attacker who wants to escalate their privileges from local user to local root on a typical SE Linux system has a significant benefit in starting from a user account instead of starting from a web server or other system process. In the SE Linux model access is granted to a domain, and the domain which is used for a process is determined by the policy based on the domain of the parent process and the labelling of the executable. Some domains are not permitted to transition to any other domains, such as the domain dhcpd_t (used for a DHCP server). Other domains are only permitted to transition to a small set of domains, for example the domain httpd_t (used for a web server) can only transition to a small number of domains none of which has any significant privileges. On a machine running without SE Linux a compromise of a DHCP server is game-over as the server runs as root. A compromise of a daemon such as Apache on a machine without SE Linux gives unrestricted access to run applications on the systems - if a SETUID-root program has a security flaw then you lose. The same bug in a SETUID program on a machine running SE Linux is not fatal because SE Linux will prevent the program from doing anything that it’s parent could not do - even if an attacker made Apache run a buggy SETUID program the broken program in question could do nothing other than what Apache is normally permitted to do. A security flaw in a SETUID-root program on a SE Linux system can still be exploited by a local user (someone who has logged in) when running the Targeted policy. When running the Strict or MLS policies many such vulnerabilities will not be exploitable by local users (for example exploiting PING would only permit network access). As a rule of thumb you should consider that a kernel security flaw will make it possible to bypass all other security features. However there are some situations where SE Linux can prevent local exploits. One example is a bug discovered in July 2006 which allowed the creation of SETUID files under /proc [2], the targeted policy of SE Linux prevented this from working. Another example is CVE-2003-0127 [3] (a kernel security flaw that was exploited by triggering a module load and then exploiting a race condition in the kernel module load process), the commonly used exploit for this did not work on a SE Linux system because the user process was not permitted the socket access used to trigger the module load (it is believed that an attacker could have written a version of the exploit to work on a SE Linux system - but AFAIK no-one ever did so).

• [1] http://etbe.coker.com.au/2007/10/08/selinux-storm/


• [2] http://lwn.net/Articles/191954/


• [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0127

Share This

Bruce Schneier has just written about the Storm Worm [1] which has apparently been quietly 0wning some Windows machines for most of this year (see the Wikipedia page for more information [2]). I have just been asked whether SE Linux would stop such a worm from the Linux environment. SE Linux does prevent many possible methods of getting local root. If a user who does not have the root password (or is not going to enter it from a user session) has their account taken over by a hostile party then the attacker is not going to get local root (unless there is a kernel vulnerability). Without local root access the activities of the attacker can be seen by a user logged in on another account - processes will be seen by all user sessions if using the SE Linux targeted policy and files and processes can be seen by the sys-admin. If while a user account is 0wned the user runs “su -” (or an equivalent command) then in theory at least the attacker can sniff this and gain local root access (whether enough users do this to make attackers feel that it’s worth their effort to write the code in question is something I couldn’t even guess about). If the user is clueless then the attacker could immediately display a dialog with some message that sound urgent and demand the root password - some users would give it. If the user is even moderately smart the attacker could fake the GUI dialogues for installing updated packages (which have been in Red Hat distributions for ages and have appeared in Debian more recently) and tell the user that they need to enter the root password to install an important security update (oh the irony). In conclusion I think that if a user is ill-educated enough to want to run a program that was sent to them in email by a random person then I expect that the program would have a good chance of coercing them into giving it local root access if the user in question had the capability of doing so. Even if a Linux trojan did not have local root access then it could still do a lot of damage. Any server operations that don’t require ports 1024 (which means most things other than running a web, DNS, or mail server) can still be performed and client access will always work (including sending email). The trojan would have access to all of the user's data (which for a corporate desktop machine usually means a huge network share of secret documents). If a trojan only attempts to perform actions that SE Linux permits (running programs from the user's home directory, accessing servers for DNS, HTTP, IRC, SMTP, and other protocols - a reasonable set of options for a trojan) then the default configuration of SE Linux (targeted policy) won't stop it or even log anything. This is not a problem with SE Linux, just a direct result of the fact that in every situation a trojan can perform all operations that the user can perform - and if the trojan only wants to receive commands via web and IRC servers and send spam via the user's regular mail server then it will be a small sub-set of the permitted operations for the user! If however the trojan tries more aggressive methods then SE Linux will log some AVC messages about access being denied. If the sys-admin has good procedures for analysing log files they will notice such things, understand what they mean, and be able to contain the damage. Also there have been at least two cases where SE Linux prevented local root exploits. Finally, in answer to the original question: SE Linux will stop some of the more aggressive methods that trojans might use. But there are still plenty of things that a trojan could do to cause harm which won't be stopped or audited by SE Linux policy. When Linux gets more market share among users with a small amount of skill and no competent person to do sys-admin work for them we will see some Linux trojans and more Linux worms. It will be interesting to see what methods the trojan authors decide to use.

• [1] http://www.schneier.com/blog/archives/2007/10/the_storm_worm.html


• [2] http://en.wikipedia.org/wiki/Storm_Worm

Share This

The C standards committee is apparently preparing to revise the C standard. The proposed C1x charter sets the goal of the committee draft’s completion in 2009, with publication of the new standard in 2012. The proposed charter adds security as a significant new goal for the standard:

Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities.

The proposed charter also sets the requirement that all new features must have a history in non-experimental compilers and be in common use.

Well, still in the planning stages... The general idea is to get a largish house in Denmark for one or two weeks, share the cost among ten people, and live a life of debauchery for one or two weeks, probably in the first or second week of January.

I decided to experiment.

This past weekend I did the absolutely insane and attended a wedding and an ordination in Vancouver, without taking any time off of work. I've finished two weeks at the new job (and am loving it! I'll post more when I have something more than "done a bunch of classes, learned confidential pieces of Google knowledge, ate great food") and didn't want to go to my boss and ask for time off in the first month.

So, Friday night, 9pm, caught flight from SFO to SEA, rented car. We were sitting in Heather's room at 4am chatting away, slowly passing out. Next day, up at 9, go visit Jamu, sort out suit rental, go for lunch, back to his moms to get dressed. I hope to link to a wedding album sometime in here. He got married by the paperclip behind the Planetarium in Vanier park. There were 4 weddings that I saw there, all peacefully contending for the various views and trying to stay out of one another's photos. =) Saturday evening, the DJ was great. We tried an experiment to see if we could leave Leif with Sandy, and whether the solid foods would be enough for a few hours. He made it a couple of hours, and then joined us at the dance, being happier knowing that we were around. It turns out Leif likes dancing! I was a little worried about the volume, and at various times several of us asked the DJ to turn it down when the music was creeping louder. It was also fun to see a whole pile of friend that I haven't seen in something like 10 years and see how we've all changed. Thanks to Facebook, at least we didn't have to completely rehash the last decade. =)

I think we turned in at 1 or 2. The next day, up at 10:30 so that we could pickup the van, pickup Katy, pickup our mail, go to the Naam to meet Ernie, Janet, and Anika, drop off the suit, pick up a snack, go to MEC, drop off Katy, and then head to the Vancouver Unitarian Church to see Laura's ordination and meet Jon.

Laura's ordination was the most amazing that I've been to. Her ministry is centered around the Faithful Fools, and the people that she's touched and been mentored by were woven throughout the ceremony. I was invited to play the recorder, so I did the last part of the prelude, and played along with the choir for "Rise up, oh flame". People were wearing silly hats, there were stories, and tears, and another pile of people that I haven't seen in ages from when I was a member at that church. I'm also not sure that I've been to that church since getting married in it, so it was nice to be in that space again.

The reason for the visit to MEC was that my goal has been to start biking home. I'd acquired a bike, helmet, lights, and lock, but wasn't happy with my visibility in black clothing on a black bike. I got ankle reflectors and a vest for the backpack, and I biked home yesterday. I'm surprisingly not that sore for the 10 mile ride home. We'll see how I'm doing in a few days. ;)

If you experience the following error:

W: GPG error: ftp://ftp.cyconet.org etch-backports Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 8B78E5581BCDFF8C You may fix it with something like:

# aptitude -t etch-backports install debian-cyconet-archive-keyring backports, Debian, Packaging, planet

If you know of an occasional passerby who takes the time to extract the contents of Debian source packages to see whether the RFCs are here or not, please let us know. We are always looking for new potential contributors.

— Josselin Mouette

Any sufficiently advanced stupidity is indistinguishable from malice.

(I have no attribution to give. Googling for it gives multiple, mutually inconsistent attributions.)

After dealing with Optus phone support [1] in regard to a routine request for a password change I have been thinking about better ways of managing password changes for a large ISP. The first criteria is that the user must have a password that is difficult to brute-force attack at all times. Changing a password to a supposedly temporary value that can be easily guessed (such as “changeme“) is never acceptable. The next criteria is that the help-desk operator should be trusted as little as possible and it would be ideal if they never knew the password. One possibility that occurred to me is that each bill could have a six-digit pseudo-random number printed on it. This number could be used as an alternate password. When a customer calls up because they lost their password they almost always have their last bill (this is why they print the number for phone support on each bill). The help-desk operator could then push a button on a web based form that makes this pseudo-random number be their new password, thus the help-desk operator would not know the new password and the user would also have it printed out clearly which avoids the confusion from having a password read out in a foreign accent. Another possibility is to have the password change infrastructure integrated with the CTI [2] system, then the help-desk operator could push a button and have the computer dictate the password without the help-desk operator being able to listen in. There will always be corner cases where a help-desk operator has to change the password, but if these are rare because the automated system handles most cases then the potential for damage would be limited. Of course it would also be a really good idea to do some statistical tracking of the number of password change requests performed by each operator and investigate those who do significantly more than average. In the past AOL has experienced a variety of security problems related to trojans [3] which probably would have been discovered by such analysis. Another possible option is that customers with mobile phones could have their new password sent to them by SMS. It’s quick, easy, cheap when done in bulk, and is much harder to intercept than most methods that might be used for transferring passwords. References:

1. http://etbe.coker.com.au/2007/09/03/optus-password-changeme/


2. http://en.wikipedia.org/wiki/Computer_telephony_integration


3. http://www.wired.com/techbiz/it/news/2003/02/57753

Share This

mod_wsgi 1.0 Yesterday the official 1.0 version of mod_wsgi was released and uploaded to unstable (the binary package you want to install is called libapache2-mod-wsgi, in case you were wondering), so I think it's a good time to blog about it. Mod_wsgi is an Apache module which can host any Python application which supports the WSGI interface (the reference is also available as package). Major applications and frameworks which are known to work well with mod_wsgi include CherryPy, Django, Karrigell, Pylons, TurboGears, web.py, MoinMoin, PyBlosxom and Trac. In fact every application which provides a WSGI compatible interface should be able to be hosted with mod_wsgi. The module is very simple to use, is very well configurable, documented, has a very active and responsive upstream author and is suitable for use in hosting high performance production web sites, as well as your average personal site. There are two common ways of operation:

• Embedded mode - working in a way similar to mod-python: The Python code is executed within the context of the Apache child process.
• Daemon mode - similar to FASTCGI/SCGI solutions, but with the important difference that a separate infrastructure is not needed when implementing the WSGI application and everything is handled automatically by mod_wsgi. Of course this mode has a smaller impact on the normal Apache child processes and also allows to run applications under different users.

If you're running python web applications which provide a WSGI interface: go and give mod_wsgi a try! ~~DISCUSSION~~

On your clients you have to modify /etc/snmp/snmpd.conf:

#com2sec paranoid default public
com2sec readonly default public
exec .1.3.6.1.4.1.2021.8.3 aptupdate /usr/local/bin/nagios-check-apt-updates Get the check script to the client:

# wget –no-check-certificate \
https://kosh.ganneff.de/ganneffutils/nagios/nagios-check-apt-updates \
-O /usr/local/bin/nagios-check-apt-updates
# chmod +x /usr/local/bin/nagios-check-apt-updates Allow the snmp user to make use of apt-get:

# echo “snmp ALL=(ALL) NOPASSWD: /usr/bin/apt-get update” >> /etc/sudoers
# echo “snmp ALL=(ALL) NOPASSWD: /usr/bin/apt-get –simulate upgrade” >> /etc/sudoers Restart the snmpd:

# /etc/init.d/snmpd restart
Restarting network management services: snmpd. On the nagios monitoring system you have to run something like this:

# /usr/lib/nagios/plugins/check_snmp -H <client> -t30 \
-C public -o .1.3.6.1.4.1.2021.8.3.101.1 \
-r “No updates available”
SNMP CRITICAL - *”Security updates (1): libkrb53; “* iso.3.6.1.4.1.2021.8.3.101.1=”Security updates (1): libkrb53; ” After upgrading the client you should get:

# /usr/lib/nagios/plugins/check_snmp -H <client> -t30 \
-C public -o .1.3.6.1.4.1.2021.8.3.101.1 \
-r “No updates available”
SNMP OK - “No updates available” iso.3.6.1.4.1.2021.8.3.101.1=”No updates available” Debian, opensource, planet

I've just accepted an job offer from Google and I'm now moving from Rio de Janeiro to Belo Horizonte!

I would like to say thank you very much for those who helped me in the Debian project until now, you know who you are.

I did upload a updated version of eGroupware to my pool. You can grab it from http://ftp.cyconet.org/debian/archive/bpo/egroupware/1.4.001.dfsg-2.1~bpo40+1/ or via:

deb ftp://ftp.cyconet.org/debian etch-backports main non-free contrib For installing the rules analog backports.org applies. Have fun! backports, bpo, Debian, opensource, planet

Earlier this year I blogged about using the twitter bot for Remember the Milk. I still use it fairly well, even though the SMS messages from the RTM come late a bit. It's working for me in order to get a good chain going for the thesis proposal. There are a couple other bots that I'm using which are on twitter as well.

The first bot that I use is the bot at timer. The timer bot will let you set a timer (surprisingly). You only need to send it a direct message with the amount of minutes as well as a reminder for you about what it was set for. For example, if you want to remember to plug the meter before it runs out in 40 minutes, just twitter 'd timer 38 plug the meter' to timer and in 38 minutes it will inform you that your timer is up. You can have multiple timers running at once, which is useful if you are perhaps having tea at a coffee shop while you are parked on the street.

Another bot I use is the gcal. Gcal is a connection to your google calendar through twitter. You can set up new appointments by messaging the gcal bot with something like 'd gcal Pick up joe at 7pm' or 'd gcal set up web application for judy tomorrow' and it will
add it to your calendar. I use it in the morning to track my weight. I just pull out my phone while I am at the scale and SMS 'd gcal my weight is XXX', and it adds the event as a day event on the day it was sent.

The last bot I will go over today is the mymm bot. It is slightly more complicated but still useful. When you're at the pump, you can direct message mymm a little info and get back the MPG that you have done since the last fillup. It helps me keep a tab on how good or bad I'm driving, which is a good thing. The car we drive usually gets about 24 MPG, but I learned through this that when I'm carrying a bunch of crap in the back, the MPG drops 3-4, so it's better for me to have an empty trunk.

I'm sure there are a bunch of other useful bots out there (ququoo is one, which I may cover in another post), but these are the most useful that I've found so far. Twitter is turning out to be much more useful than just random status updates.

Written to count votes with the d’Hondt method, released as a single C99 source file. I know I know, why did I write it in C? Well, because I felt like it. Now you don’t have to ask that question in my comment space in a rude manner

(In other news, I just uploaded darcs-monitor to Debian. It’s sitting waiting for NEW processing. In the meantime, you can get the package at the upstream distribution site.)