pidgin-sipe

The pidgin-sipe package, which allows connecting to the MS Office Communication Server ("OCS") using pidgin, is feeling lonely and unloved. It's been sitting in the bugzilla review queue for the past 4 months.

Would some kind reviewer put it out of its misery?

Bugzilla entry for pidgin-sipe

Passwords in php scripts

Putting passwords in your php scripts is dangerous for a number of reasons, as for example:

1. the php files are usually world-readable, meaning that anyone with shell access to the server has full access to your db passwords, even if they only have an unprivileged account
   
2. if you are using version control, the passwords are needlessly replicated to all the tree checkouts. If someone's home machine gets compromised, you will have to change all the database passwords as well. Changing database passwords always involves a blip in uptime because changing the password in your db software is not simultaneous with changing it in your web scripts.
   
3. the same applies if an employee in your organization leaves.
4. if for some reason the apache configuration becomes screwed up and your php handler disappears, then the server will output the php code as text, exposing all passwords contained within.
   

Or, to illustrate, let's imagine the following scenario. You have two applications, one you trust (example.com/trusted), and the other not so much (example.com/untrusted). One day there is a remote exploit in the untrusted app that allows remote code execution. This would let an attacker read any files readable by the apache process, and therefore any passwords used by the trusted application would be accessible to the attacker, if they are stored in the application source. As a consequence, the data used by the trusted application is compromised because the attacker has access to the mysql database used by /trusted.

The solution is to store these passwords separately from your main app tree and only readable by root. Doing a simple php include from somewhere outside the web tree will problem #4 above, but it still won't address the other concerns. If you have full admin control of your apache server, you can go further than that.

Apache reads config files as root, so we'll take advantage of that.

1. Create a /etc/httpd/conf.d/passwords.conf
2. Put your password information in the form:
   
   <Directory "/var/www/path/to/your/app">
       # disable phpinfo, to prevent accidental leaks
       php_admin_value disable_functions phpinfo
   
       SetEnv mysql_user_password SecretPassXX
       SetEnv some_other_password AnotherPassXX
   </Directory>
   
   
3. Set permissions on passwords.conf by doing:
   chown root:root passwords.conf
   and
   chmod 0600 passwords.conf
   Now this file is only readable by root.
4. You can now access these passwords from your scripts using:
   $_SERVER['mysql_user_password'].

The benefits of this solution are:

1. The passwords are not accessible outside your application's immediate execution environment
2. The only way an attacker can get these passwords is to execute arbitrary code in the context of your application, which is quite a bit harder than simply being able to output arbitrary files (e.g. via directory traversal vulnerabilities)
3. Underprivileged accounts, including php scripts that are executed in another directory can't get to the passwords

In terms of our example with /trusted and /untrusted, even if /untrusted gets compromised, the attacker would not be able to obtain the passwords used by /trusted (the config file containing the passwords is only readable by root, and SetEnv directives with password values are only set in /trusted location -- unavailable in /untrusted even if the attacker has full access to $_SERVER).

There are caveats with this solution as well. E.g. you have to be careful about doing things like phpinfo() or var_dump($_SERVER) (which is why I include the code to disable the phpinfo() using the php_admin_value disable_functions phpinfo parameter).

I think overall this helps significantly tighten the security of web applications, especially in shared environments.

Different SMTP relay host depending on the location

Okay, after thinking about the problem and brainstorming a bit, I came up with a solution for my "smtp from two locations" problem. The solution is tied to NetworkManager and is actually pretty straightforward (if a bit kludgy).

This is what I wrote and placed in /etc/NetworkManager/dispatcher.d/10-relayhost, and it expects to have a default installation of postfix, with at least one uncommented relayhost= line (doesn't matter what's in the line itself). By default, postfix listens on localhost:25, which is fine for me. I have configured claws-mail to always use localhost:25 as the SMTP server, and it's working just fine, automatically switching my relayhost from mcgill's to my ISP's depending on where I am at the moment. It can probably be improved further, but this is the general idea.

Of course, a better solution would be to have mailhost.mcgill.ca accept mail relaying for authenticated connections, but that's a bit of a pie in the sky at the moment.

Hope this helps someone with a similar problem.

#!/bin/sh

CONF="/etc/postfix/main.cf"
HOME="smtp.teksavvy.ca"
WORK="mailhost.mcgill.ca"

if [ "$2" = "up" ]; then
 if `/sbin/ifconfig | grep -q 'inet addr:192.168.1.'`; then
     # we're at home
     sed -i -e "s/^relayhost=.*/relayhost=${HOME}/g" ${CONF}
 elif `/sbin/ifconfig | grep -q 'inet addr:132.2'`; then
     # we're at work
     sed -i -e "s/^relayhost=.*/relayhost=${WORK}/g" ${CONF}
 else
     # we're elsewhere, unset relayhost and hope for the best
     sed -i -e "s/^relayhost=.*/relayhost=/g" ${CONF}
 fi
 /sbin/service postfix reload
fi

SMTP question

I must confess -- I expected that I would have a bit of a rough time configuring my new Thinkpad X200s with F11, but everything worked like magic "out of the box," with no tinkering necessary. I'm blown away!

But, dear lazyweb... I have an SMTP question. I use this laptop both at work and at home -- but I can't use the same SMTP host in both locations. The mailhost at work only allows relaying from internal networks, and doesn't offer "relay if authenticated" service to external addresses (because most people use exchange over mapi, and nobody thus bothers to set up authenticated SMTP relaying for people without outlook). My ISP probably supports authenticated SMTP, but it's silly to use it from work.

VPN is one option, but it's a bit silly to have to start up VPN just to send an email. Ssh or stunnel is another option, but is also sub-optimal. What I really need is a way for a service like ssmtp or esmtp to automatically recognize which network I'm currently on and use either my company's mailhost if I'm at work, or my ISP's mailhost if I'm at home.

My google-fu is failing me. I know ssmtp has "identities" but they aren't very useful in this case because both at home and at work I use the same "from" address. I can't be the only one with this problem. Anyone?

Changing lanes

In the backyard
Originally uploaded by mricon

Man, with all this microblogging and facebooking going on, I rarely get around to updating my actual blog. I guess it's only to be expected.

In less than 3 weeks' time I'll be leaving my position as lead programmer for McGill's web team and starting another job as a Senior IT Security Analyst for McGill's IT Security department. It's a bit of a departure from what I have been doing for the past little while, but not that drastic of a change. Security is an integral part of being a web programmer and a sysadmin -- and I had a chance to have my butt in both those chairs in the past 4 years at McGill.

Actually, one of the reasons why I wanted to switch was because slowly but gradually the McGill web team has lost its sysadmin privileges, and I rather miss being able to tinker with Linux. For example, I almost made everything work under SELinux at some point (which necessitated writing a few policies of our own), but unfortunately SELinux is not something that is supported by the central sysadmin team. Perhaps it's something I can tackle in the future. :)

And just overall I've been feeling like I've been stagnating doing the same old web stuff year after year. I feel like it's time for change. The new job will probably a bit more stressful than my old one -- but I say bring it on. :)

In unrelated news, Lev is turning 9 months this weekend. He's excited about it, see? :)

Geeky cubicle humour

Geeky cubicle humour
Originally uploaded by mricon

It says "I have no idea, but it looks pretty." Hang it in your cubicle, and when someone asks you what it says, you can honestly tell them. ;)

PDF version

(Yes, I'm still actively trying to learn Chinese. By the way, if you haven't yet tried Anki for your flashcards, you totally should, especially with the pinyin toolkit plugin. It's pure awesomeness. If you're learning Japanese, there's a couple of awesome plugins for it, too, plus it integrates nicely with smart.fm -- if you're into that sort of thing).

Home power usage report system

You know what I'd love to see? Some kind of utility that would show me the kWh power usage of my appliances in real-time. You've all seen the output of "top" -- something like this (numbers picked randomly, so don't pay any attention to them):

load average (kWh): 270, 220, 230
Appliances: 149 total

Appliance  kWh  %tot
Fridge     130    60
Stove       90    30
Desk lamp   60    10

This can be done -- today, easily and cheaply. Here's how:

1. Have a simple device that sits on a circuit and measures the power consumption. Kind of like the Kill-a-watt, except without the readout screen and the buttons. These devices can probably be easily built-in into outlets and power bars.
   
2. The sensor has a unique identifier (similar to a mac address). This identifier is clearly labelled on the outlet.
   
3. Every N seconds/minutes the sensor broadcasts the consumption data along the power line (just like "smart meters" do). Something like "00:0b:db:79:4e:45#120W" to indicate that the sensor with a unique id "00:0b:db:79:4e:45" is currently reporting 120 watts.
   
4. A listener device plugs in to the power grid in your home and collects the reports, which it then either presents on a readout screen, or makes available to the network via, say, an SNMP service.
5. You have some fairly simple software on your computer that connects to the listener device and shows you real-time power usage using nice graphs. You can give human-friendly labels to the sensors to identify them for your own use (e.g. you locate the outlet labelled "00:0b:db:79:4e:45" and know that it's where your fridge is plugged in, so you label that sensor as "Fridge" in your software).
6. The software can even present the graphs in real money instead of kWh -- this way you'll know that the lights you left on in the bedroom are currently costing you 2 cents per hour, and the 1000W heater you leave on in your garage just in case you have to go down there runs up a nice $2.00 a day.

I'm not an electrical engineer, but I'm pretty sure this is very easy to implement. The sensor shouldn't cost very much, as it's really just a simple watt sensor and a non-programmable broadcaster. The listener device would be a bit more, but should cost about as much as an off-the-shelf wireless router, or less (and can probably be made to fit into breaker panels, providing just a network jack out).

Judging from how much us geeks are obsessed about things like network graphs and memory graphs, I'd say that a system like this would prove pretty popular. Does someone care to take it and run with it? :)

(I have no idea if this has occurred to anyone else before, or if similar systems are already available out there. I didn't find anything from superficial googling, so I assume that no).

Arch is the new Ubuntu

This discussion on Reddit (yes-yes, it's my vice), reminded me of my earlier blog post that I wrote back in January of 2007. Reproducing it here, since my LJ blog is now defunct:

Ubuntu is the new Gentoo

2007-01-29 13:40:00

Have you noticed that there have been a lot fewer Gentoo fanboys around since, say, mid-last year? I am fairly positive that's because they have all moved on to the "new hot" distribution -- namely, Ubuntu. I guess compiling everything with "-O 99 --funroll-loops" is out, and "brown gradients" is in, I don't honestly know.

Now, the situation is slightly different in the sense that as opposed to Gentoo, which was entirely grassroots, Ubuntu has enough money coming from the "bdfl" to pay the developers and keep the PR machine well-oiled. When the fanboys move on to some other distro that is newer and shinier, I don't think the drop in popularity would be quite as drastic, but I do believe it will still be very pronounced. When the "newness factor" dies down, I expect that most developers not actually paid by Ubuntu will move back to Debian [...], and Ubuntu will take its earned slot in the distro line-up -- hopefully the company makes enough money by then to break even. Free OS market is a very tough place to compete with the likes of Red Hat and SUSE Novell Microsoft (okay, now I'm just being mean :)).

In case some people think this post is anti-Ubuntu -- it is not. [...] I simply suspect that current popularity of Ubuntu is mostly due to the "crowd" factor, and not due to its (many) merits. If anything, this is an attempt at predicting that in another year's time we'll see another project emerge (um...) that will attract many of the current Ubuntu "rabid fans" the way Gentoo and Mandrake have done in the past.

Judging from a few comments in the Reddit thread, it seems that Arch Linux is shaping up to become the new "distro for the cool." We probably won't see as much of an exodus from Ubuntu as we saw from Gentoo -- precisely because Ubuntu has a large bank account propping it up, as opposed to poor 'ole Gentoo -- but there will probably be a very pronounced dip. It seems to me (again, from that Reddit discussion) that some of the true fans of Ubuntu will be quite happy if this event takes place and takes some of the "ubuntards" out of their pool.

Fedora, on the other hand, will probably never be a "cool" distro to use -- mostly because Red Hat is seen by many "fanboys" as a big evil corp that's too mainstream to ever consider. There's probably a good reason to be happy with that state of things. :)

Second part of the "Treasure Island"

Good grief, I'm doing something short and without so many damn songs next. ;)

The second part is longer, funnier, and even more ridiculous. For more info, see my fansubs blog.

Excerpt:

New subs: Kievnauchfilm's "Treasure Island" (part 1)

New subs release: Kievnauchfilm's "Treasure Island." Only first part so far, but it's a long-ish cartoon, so it's taking me a while. :) See my subs blog for more info: subs.mricon.com.

Excerpt from the cartoon: