Ethernet Interface Naming

August 11, 2010 | etbe

As far as I recall the standard for naming Linux Ethernet devices has always been ethX where X is a number starting at 0. Until fairly recently the interface names were based on the order that device drivers were loaded or the order in which the PCI bus was scanned. This meant that after hardware changes (replacing network cards or changing the BIOS settings related to the PCI bus) it was often necessary to replace Ethernet cables or change the Linux network configuration to match the renumbering. It was also possible for a hardware failure to cause an Ethernet card to fail to be recognised on boot and thus change the numbers of all the others!

In recent times udev has managed the interface naming. In Debian the file /etc/udev/rules.d/70-persistent-net.rules can be edited to change the names of interfaces, so no matter the scanning order as long as an interface retains it’s MAC address it will get the correct name – or at least the name it initially had. One of the down-sides to the way this operates is that if you remove an old Ethernet card and replace it with a new one then you might find that eth1 is your first interface and there is no eth0 on the system – this is annoying for many humans but computers work quite well with that type of configuration.

I’ve just renamed the interfaces on one of my routers by editing the /etc/udev/rules.d/70-persistent-net.rules file and rebooting (really we should have a utility like /sbin/ip with the ability to change this on a running system).

I have decided to name the Ethernet port on the motherboard mb0. The PCI slots are named A, B, and C with A being the bottom one and when there are two ports on a PCI card the one closest to the left side of the system (when viewed from the front – the right side when viewed from the read) is port 0 on that card. So I have interfaces pcia0, pcia1, pcib0, pcib1, and pcic0. Now when I see a kernel message about the link going down on one of my ports I won’t have to wonder which port has the interface name eth4.

I did idly consider naming the Ethernet devices after their service, in which case I could have given names such as adsl and voip (appending a digit is not required). Also as the names which are permitted are reasonably long I could have used names such as mb0-adsl, although a hyphen character might cause problems with some of the various utilities and boot scripts – I haven’t tested out which characters other than letters and digits work. I may use interface names such as adsl for systems that run at client sites, if a client phoned me to report Internet problems and messages on the console saying things like “adsl NIC Link is Down” then my process of diagnosing the problem would become a lot easier!

Does anyone else have any good ideas for how to rename interfaces to make things easier to manage?

I have filed Debian bug report #592607 against ppp requesting that it support renaming interfaces. I have also filed Debian bug report #592608 against my Portslave package requesting that provide such support – although it may be impossible for me to fix the bug against Portslave without fixing pppd first (I haven’t looked at the pppd code in question for a while). Thanks to Rusty for suggesting this feature during the Q/A part of my talk about Portslave for the Debian mini-conf in LCA 2002 [1].

[1] http://www.linux.org.au/conf/2002/debiancon.html

Why Clusters Usually Don’t Work

August 4, 2010 | etbe

It’s widely regarded that to solve reliability problems you can just install a cluster. It’s quite obvious that if instead of having one system of a particular type you have multiple systems of that type and a cluster configured such that broken systems aren’t used then reliability will increase. Also in the case of routine maintenance a cluster configuration can allow one system to be maintained in a serious way (EG being rebooted for a kernel or BIOS upgrade) without interrupting service (apart from a very brief interruption that may be needed for resource failover). But there are some significant obstacles in the path of getting a good cluster going.

Buying Suitable Hardware

If you only have a single server that is doing something important and you have some budget for doing things properly then you really must do everything possible to keep it going. You need RAID storage with hot-swap disks, hot-swap redundant PSUs, and redundant ethernet cables bonded together. But if you have redundant servers then the requirement for making one server reliable is slightly reduced.

Hardware is getting cheaper all the time, a Dell R300 1RU server configured with redundant hot-plug PSUs, two 250G hot-plug SATA disks in a RAID-1 array, 2G of RAM, and a dual-core Xeon Pro E3113 3.0GHz CPU apparently costs just under $2,800AU (when using Google Chrome I couldn’t add some necessary jumper cables to the list so I couldn’t determine the exact price). So a cluster of two of them would cost about $5,600 just for the servers. But a Dell R200 1RU server with no redundant PSUs, a single 250G SATA disk, 2G of RAM, and a Core 2 Duo E7400 2.8GHz CPU costs only $1,048.99AU. So if a low end server is required then you could buy two R200 servers that have no redundancy built in which cost less than a single server that has hardware RAID and redundant PSUs. Those two servers have different sets of CPU options and probably other differences in the technical specs, but for many applications they will probably both provide more than adequate performance.

Using a server that doesn’t even have RAID is a bad idea, a minimal RAID configuration is a software RAID-1 array which only requires an extra disk per server. That takes the price of a Dell R200 to $1,203. So it seems that two low-end 1RU servers from Dell that have minimal redundancy features will be cheaper than a single 1RU server that has the full set of features. If you want to serve static content then that’s all you need, and a cluster can save you money on hardware! Of course we can debate whether any cluster node should be missing redundant hot-plug PSUs and disks. But that’s not an issue I want to address in this post.

Also serving static content is the simplest form of cluster, if you have a cluster for running a database server then you will need a dual-attached RAID array which will make things start to get expensive (or software for replicating the data over the network which is difficult to configure and may be expensive), so while a trivial cluster may not cost any extra money a real-world cluster deployment is likely to add significant expense.

My observation is that most people who implement clusters tend to have problems getting budget for decent hardware. When you have redundancy via the cluster you can tolerate slightly less expected uptime from the individual servers. While we can debate about whether a cluster member should have redundant PSUs and other expensive features it does seem that using a cheap desktop system as a cluster node is a bad idea. Unfortunately some managers think that a cluster solves the reliability problem and therefore you can just use recycled desktop systems as cluster nodes, this doesn’t give a good result.

Even if it is agreed that server class hardware is used for all servers so features such as ECC RAM are used you will still have problems if someone decides to use different hardware specs for each of the cluster nodes.

Testing a Cluster

Testing a non-clustered server or some servers that use a load-balancing device at the front-end isn’t that difficult in concept. Sure you have lots of use cases and exception conditions to test, but they are all mostly straight-through tests. With a cluster you need to test node failover at unexpected times. When a node is regarded as having an inconsistent state (which can mean that one service it runs could not be cleanly shutdown when it was due to be migrated) it will need to be rebooted which is sometimes known as a STONITH. A STONITH event usually involves something like IPMI to cut the power or a command such as “reboot -nf“, this loses cached data and can cause serious problems for any application which doesn’t call fsync() as often as it should. It seems likely that the vast majority of sysadmins run programs which don’t call fsync() often enough, but the probability of losing data is low and the probability of losing data in a way that you will notice (IE it doesn’t get automatically regenerated) is even lower. The low probability of data loss due to race conditions combined with the fact that a server with a UPS and redundant PSUs doesn’t unexpectedly halt that often means that problems don’t get found easily. But when clusters have problems and start calling STONITH the probability starts increasing.

Getting cluster software to work in a correct manner isn’t easy. I filed Debian bug #430958 about dpkg (the Debian package manager) not calling fsync() and thus having the potential to leave systems in an inconsistent or unusable state if a STONITH happened at the wrong time. I was inspired to find this problem after finding the same problem with RPM on a SUSE system. The result of applying a patch to call fsync() on every file was bug report #578635 about the performance of doing so, the eventual solution was to call sync() after each package is installed. Next time I do any cluster work on Debian I will have to test whether the sync() code seems to work as desired.

Getting software to work in a cluster requires that not only bugs in system software such as dpkg be fixed, but also bugs in 3rd party applications and in-house code. Please someone write a comment claiming that their favorite OS has no such bugs and the commercial and in-house software they use is also bug-free – I could do with a cheap laugh.

For the most expensive cluster I have ever installed (worth about 4,000,000 UK pounds – back when the pound was worth something) I was not allowed to power-cycle the servers. Apparently the servers were too valuable to be rebooted in that way, so if they did happen to have any defective hardware or buggy software that would do something undesirable after a power problem it would become apparent in production rather than being a basic warranty or patching issue before the system went live.

I have heard many people argue that if you install a reasonably common OS on a server from a reputable company and run reasonably common server software then the combination would have been tested before and therefore almost no testing is required. I think that some testing is always required (and I always seem to find some bugs when I do such tests), but I seem to be in a minority on this issue as less testing saves money – unless of course something breaks. It seems that the need for testing systems before going live is much greater for clusters, but most managers don’t allocate budget and other resources for this.

Finally there is the issue of testing issues related to custom code and the user experience. What is the correct thing to do with an interactive application when one of the cluster nodes goes down and how would you implement it at the back-end?

Running a Cluster

Systems don’t just sit there without changing, you have new versions of the OS and applications and requirements for configuration changes. This means that the people who run the cluster will ideally have some specialised cluster skills. If you hire sysadmins without regard to cluster skills then you will probably end up not hiring anyone who has any prior experience with the cluster configuration that you use. Learning to run a cluster is not like learning to run yet another typical Unix daemon, it requires some differences in the way things are done. All changes have to be strictly made to all nodes in the cluster, having a cluster fail-over to a node that wasn’t upgraded and can’t understand the new data is not fun at all!

My observation is that the typical experience of having a team of sysadmins who have no prior cluster experience being hired to run a cluster usually involves “learning experiences” for everyone. It’s probably best to assume that every member of the team will break the cluster and cause down-time on at least one occasion! This can be alleviated by only having one or two people ever work on the cluster and having everyone else delegate cluster work to them. Of course if something goes wrong when the cluster experts aren’t available then the result is even more downtime than might otherwise be expected.

Hiring sysadmins who have prior experience running a cluster with the software that you use is going to be very difficult. It seems that any organisation that is planning a cluster deployment should plan a training program for sysadmins. Have a set of test machines suitable for running a cluster and have every new hire install the cluster software and get it all working correctly. It’s expensive to buy extra systems for such testing, but it’s much more expensive to have people who lack necessary skills try and run your most important servers!

The trend in recent years has been towards sysadmins not being system programmers. This may be a good thing in other areas but it seems that in the case of clustering it is very useful to have a degree of low level knowledge of the system that you can only gain by having some experience doing system coding in C.

It’s also a good idea to have a test network which has machines in an almost identical configuration to the production servers. Being able to deploy patches to test machines before applying them in production is a really good thing.

Conclusion

Running a cluster is something that you should either do properly or not at all. If you do it badly then the result can easily be less uptime than a single well-run system.

I am not suggesting that people avoid running clusters. You can take this post as a list of suggestions for what to avoid doing if you want a successful cluster deployment.

Pre-Meeting Lightning Talks

August 3, 2010 | etbe

This evening I arrived at the LUV [1] meeting half an hour before it started. I was one of about a dozen people sitting in the room waiting, some of us had laptops and were reading email but others just sat quietly – the venue is sometimes open as much as an hour before the event starts and in bad weather some people arrive early because it’s more comfortable than anywhere else that they might hang out.

So I went to the front and suggested that instead of just doing nothing we get some short talks about random Linux things to fill the time. This seems to be a good opportunity for people to practice their public speaking skills, share things that interest them with a small and friendly audience, and keep everyone else entertained.

With some prompting a few members of the audience got up and spoke about Linux things that they were doing or had recently read about. They were all interesting and I learned a few things. I considered giving a talk myself (my plan B was to just speak for 15 minutes about random Linux stuff I’m doing) but decided that it would be best if I just encouraged other people to give talks.

I have suggested to the committee that we plan to do this in future and maybe have a mention of it on the web site to encourage people who are interested in such things (either speaking or listening) to attend early enough.

I think that this concept has been demonstrated to work and should also work well in most other user group meetings of a suitable size. At LUV we typically have about 60 people attend the main meeting and maybe a dozen arrive really early so people who would be nervous about speaking to an audience of 60 may feel more comfortable. For a significantly larger group (where you have maybe 300 people attend the main meeting and 60 arrive early) the dynamic would be quite different, instead of having more nervous people give talks you might find that a membership of 300 gives a significant number of people who have enough confidence to give an impromptu short lecture to an audience of 60.

As an aside the Connected Community Hackerspace [2] is having a meeting tonight to decide what to do about an office in a central Melbourne area. One of the many things that a Hackerspace can be used for is a meeting venue for lightning talks etc.

Creating a SE Linux Chroot environment

July 26, 2010 | etbe

Why use a Chroot environment?

A large part of the use of chroot environments is for the purpose of security, it used to be the only way of isolating a user from a section of the files on a server. In many of the cases where a chroot used to be used for security it is now common practice to use a virtual server. Also another thing to note is that SE Linux provides greater access restrictions to most daemons than a chroot environment would so in many case using SE Linux with a sensible policy is a better option than using a chroot environment to restrict a daemon. So it seems to me that the security benefits that can be obtained by using a chroot environment have been dramatically decreased over the last 5+ years.

One significant benefit of a chroot environment is that of running multiple different versions of software on one system. If for example you have several daemons that won’t run correctly on the same distribution and if you don’t want to have separate virtual machines (either because you don’t run a virtualisation technology or because the resources/expense of having multiple virtual servers is unacceptable) then running multiple chroot environments is a reasonable option.

The Simplest Solution

The simplest case is when all the chroot environments are equally trusted, that means among many other things that they all have the latest security patches applied. Then you can run them all with the same labels, so every file in the chroot environment will have the same label as it’s counterpart in the real root – this will mean that for example a user from the real root could run /chroot/bin/passwd and possibly get results you don’t desire. But it’s generally regarded that the correct thing to do is to have a chroot environment on a filesystem that’s mounted nosuid which will deal with most instances of such problems. One thing to note however is that the nosuid mount option also prevents SE Linux domain transitions, so it’s not such a good option when you use SE Linux as domain transitions are often used to reduce the privileges assigned to the process.

There are two programs for labeling files in SE Linux, restorecon is the most commonly used one but there is also setfiles which although being the same executable (restorecon is a symlink to setfiles) has some different command-line options. The following command on a default configuration of a Debian/Lenny system will label a chroot environment under /chroot with the same labels as the main environment:

setfiles -r /chroot /etc/selinux/default/contexts/files/file_contexts /chroot

I am considering adding an option to support chroot environments to restorecon, if I do that then I will probably back-port it to Lenny, but that won’t happen for a while.

For a simple chroot once the filesystem is labelled it’s ready to go, then you can start daemons in the chroot environment in the usual way.

Less trusted Chroot environments

A reasonably common case is where the chroot environment is not as trusted. One example is when you run an image of an old server in a chroot environment. A good way of dealing with this is to selectively label parts of the filesystem as required. The following shell code instructs semanage to add file contexts entries for a chroot environment that is used for the purpose of running Apache. Note that I have given specific labels to device nodes null and urandom and the socket file log in the /dev directory of the chroot environment (these are the only things that are really required under /dev), and I have also put in a rule to specify that no other files or devices under /dev should be labelled. If /dev is bind mounted to /chroot/dev then it’s important to not relabel all the devices to avoid messing up the real root environment – and it’s impractical to put in a specific rule for every possible device node. Note that the following is for a RHEL4 chroot environment, other distributions will vary a little some of the file names.

semanage -i – << END
fcontext -a -t root_t -f -d /chroot
fcontext -a -t bin_t “/chroot/bin.*”
fcontext -a -t usr_t “/chroot/usr.*”
fcontext -a -t usr_t “/chroot/opt.*”
fcontext -a -f -d /chroot/dev
fcontext -a -f -s -t devlog_t /chroot/dev/log
fcontext -a -f -c -t null_device_t /chroot/dev/null
fcontext -a -f -c -t urandom_device_t /chroot/dev/urandom
fcontext -a -t "<<none>>" "/chroot/dev/.*"
fcontext -a -t "<<none>>" "/chroot/proc.*"
fcontext -a -t lib_t “/chroot/lib.*”
fcontext -a -t lib_t “/chroot/usr/lib.*”
fcontext -a -t bin_t “/chroot/usr/bin.*”
fcontext -a -t httpd_exec_t -d — /chroot/usr/bin/httpd
fcontext -a -t var_t “/chroot/var.*”
fcontext -a -t var_lib_t “/chroot/var/lib.*”
fcontext -a -t httpd_var_lib_t “/chroot/var/lib/php.*”
fcontext -a -t var_log_t “/chroot/var/log.*”
fcontext -a -t var_log_t -f — “/chroot/var/log/horde.log.*”
fcontext -a -t httpd_log_t “/chroot/var/log/httpd.*”
fcontext -a -t var_run_t “/chroot/var/run.*”
fcontext -a -t httpd_var_run_t -f — /chroot/var/run/httpd.pid
fcontext -a -t httpd_sys_content_t “/chroot/var/www.*”
END

You could create a shell script to run the above commands multiple times for multiple separate Apache chroot environments.

If there is a need to isolate the various Apache instances from each other (as opposed to just protecting the rest of the system from a rogue Apache process) then you could start each copy of Apache with a different MCS sensitivity label which will provide adequate isolation for most purposes as long as no sensitivity label dominates the low level of any of the others. If you do that then the semanage commands require the -r option to specify the range. You could have one chroot environment under /chroot-0 with the sensitivity label of s0:c0 for it’s files and another under /chroot-1 with the sensitivity label of s0:c1 for it’s files. To start one environment you would use a command such as the following:

runcon -l s0:c0 setsid chroot /chroot-0 /usr/sbin/httpd

SE Linux status in Debian/Squeeze

July 25, 2010 | etbe

ffmpeg

I’ve updated my SE Linux repository for Squeeze to include a modified version of the ffmpeg packages without MMX support for the i386 architecture. When MMX support is enabled it uses assembler code which requires text relocations (see Ulrich Drepper’s documentation for the explanation of this [1]). This makes it possible to run programs such as mplayer under SE Linux without granting excessive access – something which we really desire because mplayer will usually be dealing with untrusted data. In my past tests with such changes to ffmpeg on my EeePC701 have resulted in no difference to my ability to watch movies from my collection, the ones that could be played without quality loss on a system with such a slow CPU could still be viewed correctly with the patched ffmpeg.

$ mplayer
mplayer: error while loading shared libraries: /usr/lib/i686/cmov/libswscale.so.0: cannot restore segment prot after reloc: Permission denied

The AMD64 architecture has no need for such patches, presumably due to having plenty of registers. I don’t know whether other architectures need such patches, they might – the symptom is having mplayer abort with an error such as the above when running in Enforcing Mode.

The below apt sources.list line can be used to add my SE Linux repository:

deb http://www.coker.com.au squeeze selinux

dpkg

In my repository for i386 and AMD64 architectures I have included a build of dpkg that fixes bug #587949. This bug causes some sym-links and directories to be given the wrong label by dpkg when a package is installed. Usually this doesn’t impact the operation of the system and I was unable to think of a situation where it could be a security hole, but it can deny access in situations where it should be granted. I would appreciate some help in getting the patch in a form that can be accepted by the main dpkg developers, the patch I sent in the bug report probably isn’t ideal even though it works quite well – someone who knows absolutely nothing about SE Linux but is a good C coder with some knowledge of dpkg could beat it into shape.

In my repository I don’t currently provide any support for architectures other than i386 and AMD64. I could be persuaded to do so if there is a demand. How many people are using Debian SE Linux on other architectures? Of course there’s nothing stopping someone from downloading the source from my AMD64 repository and building it for another architecture, I would be happy to refer people to an APT repository that someone established for the purpose of porting my SE Linux packages to another architecture.

Policy

selinux-policy-default version 20100524-2 is now in Testing. It’s got a lot of little fixes and among other things allows sepolgen-ifgen to work without error which allows using the -R option of audit2allow – see my post about audit2allow and creating the policy for milters for defails [2].

I have uploaded selinux-policy-default version 20100524-3 to Unstable. It has a bunch of little fixes that are mostly related to desktop use. You can now run KDE4 on Unstable in enforcing mode, login via kdm and expect that everything will work – probably some things won’t work, but some of my desktop systems work well with it. I have to admit that not all of my desktop systems run my latest SE Linux code, I simply can’t have all my systems run unstable and risk outages.

Let me know if you find any problems with desktop use of the latest SE Linux code, it’s the focus of my current work. But if you find problems with chrome (from Google) or the Debian package chromium-browser then don’t report them to me. They each use their own version of ffmpeg in the shared object /usr/lib/chromium-browser/libffmpegsumo.so which has text relocations and I don’t have time to rebuild chromium-browser without text relocations – I’ll make sure it does the right thing when they get it working with the standard ffmpeg libraries. That said the text relocation problem doesn’t seem to impact the use of Chromium, Youtube doesn’t work even when the browser is run in permissive mode.

GNOME is a lower priority than KDE for me at this time. But the only area where problems are likely to occur is with gdm and everything associated with logging in. Once your X session starts up GNOME and KDE look pretty similar in terms of access control. I would appreciate it if someone could test gdm and let me know how it goes. I’ll do it eventually if no-one else does, but I’ve got some other things to fix first.

Digital Video Cameras

July 20, 2010 | etbe

I’ve just done some quick research on Digital Video Cameras for some relatives. It seems to me that the main feature that is necessary is Full HD (1920*1080) resolution as everyone seems to be getting 1920*1080 resolution monitors (getting smaller doesn’t save enough money to be worth-while). Resolutions higher than 1920*1080 will probably available in affordable monitors in the next few years, so the ability of programs like mplayer to zoom videos will probably be required even for Full HD video soon. Saving maybe $300 on a video camera while getting a lower resolution doesn’t seem like a good idea.

The next feature is optical zoom, most cameras are advertised with features such as “advanced zoom” to try and trick customers, cameras which advertise 60* or better zoom often turn out to only have 20* zoom. I think that about 20* optical zoom should be considered the minimum, not that there is anything special about 20* zoom, it’s just that there is a good range of cameras with better zoom capacity.

Image stabilisation is a required feature, no-one can keep their hand perfectly steady and the typically a DVC only gets hand-held use – most people who own them don’t even own a tripod! Digital image stabilisation is apparently not nearly as good as optical image stabilisation, and image stabilisation that involves moving the CCD is apparently somewhere in between.

Finally it’s good to have the ability to take quality photos as few people will want to carry a Digital Camera and a Digital Video Camera.

I did a search for DVCs on the web site of Ted’s Camera store (a chain of camera stores in Australia that generally provide good service at a competitive price – but not the cheapest price). The best of the Ted’s options seems to be the Panasonic SD60 HD Video [1] which does 25* optical zoom, 1920*1080i video, 5 megapixel still photography, and optical image stabilisation – it costs $750 from Ted’s.

The next best option seems to be the Sony Handycam HDR-CX110 HD [2] which does 25* optical zoom, 1920*1080i video, 3.1 megapixel 2048*1536 still photography, and digital image stabilisation. The Panasonic seems to be a better option due to having optical image stabilisation and a higher resolution for still photographs. It is also $750 from Ted’s.

Now there’s the issue of how well the cameras work on Linux. A quick Google search indicated that the Sony cameras present themselves as USB card readers and can be mounted on a Linux system, I couldn’t discover anything about the Panasonic. If I was going to buy one I would take my Netbook to the store and do a quick test.

I don’t have enough information to recommend either of those cameras, they may have some awful defects that are only apparent when you use them. But in terms of features they seem pretty good. The Panasonic SD60 HD Video should be a good benchmark when comparing cameras in the store. If nothing else the camera store staff seem to not be very helpful if asked generic questions such as “which camera is best”, but if asked questions such as “how is this other camera better than the one I’m looking at” they can usually give good answers.

If anyone has any other advice for purchasing a DVC then please let me know. Either generic advice or specific examples of Linux-friendly DVCs that have been purchased recently.

Is Lebara the Cheapest Mobile Phone company in Australia?

July 5, 2010 | etbe

My parents have just got a mobile phone with a Lebara pre-paid SIM [1]. Lebara advertise free calls to other Lebara phones but have a disclaimer that they charge a 25 cent flagfall and charge 15 cents per minute after the first 10 minutes – which is still cheaper than most mobile calls although not as good as some other mobile telcos such as Three that offer completely free calls to other phones with the same provider.

Lebara’s main selling point seems to be cheap international calls, half a cent per minute to Thailand, 1 cent per minute to Hong Kong, Indonesia and Singapore and 3 cents per minute to Bangladesh and China. Strangely calls to the US are 5 cents per minute and to Japan are 7 cents per minute, I would have expected that calling developed countries would have been cheaper due to better infrastructure and more competition. The trend of more developed countries having less expensive calls seems clear, some very undeveloped countries cost as much as $2 per minute! Note that all these rates are for calls to land-lines (calls to mobiles cost more) and are based on the new prices that apply after the 13th of July (it’s slightly cheaper for the next 8 days).

It seems really strange that calls to land-lines in Australia cost 15 cents per minute which is more than twice as much as calls to the US and Japan. In theory it would be possible to redirect calls to Australian land-lines via the US or Japan to save money. In practice it’s probably possible to do so by setting up a PBX in Thailand, Hong Kong, or Singapore.

But what I think is most noteworthy about Lebara is the fact that the call credit lasts for 90 days (this is in the FAQ). The cheapest top-up is $10 so therefore the minimum cost for mobile phone service is $40 per annum. Given the importance of owning a mobile phone to job seekers I think that with the current state of the economy there are a lot of people who could do with such a phone.

If anyone knows of Australian mobile phones that provide cheaper calls to other countries or a cheaper minimum annual fee then please let me know via the comments section.

For international readers, all prices are in Australian cents – which are worth about 85% as much as US cents.

[1] http://www.lebara-mobile.com.au/

Virtual Hosting Prices

June 22, 2010 | etbe

Linode has just announced a significant increase in the amount of RAM in each of their plans [1].

The last time I compared virtual hosting prices in a serious manner was over two years ago [2], so it seems like a good time to compare the prices again.

Now there are some differences between these providers that make things difficult to compare. Gandi used to not include the OS in the disk allocation – presumably they did de-duplication, I’m not sure if they still do that. OpenVZ/Virtuozzo and Xen can’t be directly compared. OpenVZ is an Operating System Level Virtualisation that allows virtual machines to share resources to some extent which should allow better overall utilisation of the system but may allow someone to hog more resources than they deserve – I prefer virtual machines so tend to avoid that. Virtuozzo is a technology I’m not familiar with so with all things being equal I would choose Xen because I know it better.

Years ago Vpsland deleted one of my DomUs without good notification and without keeping a backup and I’m not about to forgive them. XenEurope and Gandi get good reviews, but I have no personal experience with them so in my personal ranking they are below Linode and Slicehost.

RapidXen offers native IPv6 – a very noteworthy feature. But they are quite expensive.

Note that I have only included providers that advertise in English. I could use Google translation to place an order on a non-English web site but I am not going to risk a situation where Google translation is needed for technical support.

In the price comparison tables I have used $US for price comparisons, where the price was advertised in another currency I put the $US price in brackets. For every provider that doesn’t advertise prices in $US I used XE.com to get a spot price. Note that if you convert between currencies you will not get that rate, I used the spot rate because most of my readers don’t use the $US as their native currency (either due to living in a country that uses it or having business interests based on the $US) – converting from $AU to $US has about the same overhead for me as converting to the Euro or pound.

The bandwidth is listed as either a number of Gigabytes per month that can be transferred or as a number of Megabits per second that the connection may use.

I have tried to roughly order the offerings based on how good they seem to be. But as there are so many factors to consider it’s quite obvious that no provider can be considered to be universally better than the others.

The biggest surprise for me was how well Xen Europe compares to the others. Last time I did the comparison they were not nearly as competitive.

Finally note that I am comparing the options for low-end servers. These are services that are useful for hobbyist use and low-end servers for commercial use. Some providers such as Xen Europe exclude themselves from consideration for serious commercial use by not offering big servers – Xen Europe only supports up to 1GB of RAM.

Prices of Xen virtual servers:

ISP	RAM	Disk	Bandwidth	Price
XenEurope	128M	10G	1TB	E5 ($6.15)
XenEurope	512M	30G	1TB	E17.50 ($21.52)
Linode	512M	16G	200GB	$20
RackVM	128M	10G	100GB	#4UK ($5.90)
RackVM	512M	30G	300GB	#16UK ($23.62)
Slicehost	256M	10G	150GB	$20
Slicehost	512M	20G	300GB	$38
Gandi	256M	8G	5Mb/s	$16
Gandi	512M	16G	10Mb/s	$32
RapidXen	256M	20G	2Mb/s	$20
RapidXen	512M	20G	2Mb/s	$30
Rimuhosting	160M	4G	30GB	$20
Rimuhosting	400M	8G	150GB	$30

Prices of non-Xen virtualisation systems:

ISP	Virtualisation	RAM	Disk	Bandwidth	Price
Quantact	OpenVZ	256M	15G	300GB	$15
Quantact	OpenVZ	512M	35G	600GB	$35
FreeVPS	VMWare	256M	10G	100GB	#10UK ($14.76)
FreeVPS	VMWare	512M	20G	200GB	#15UK ($22.14)
Vpsland	Virtuozzo	512M	10G	250GB	$20
Vpsland	Virtuozzo	1024M	20G	500GB	$35

Update: Added RackVM to the listing, and removed the ambiguous part about Gandi disk allocation.

Carpal Tunnel – Getting Better

June 16, 2010 | etbe

Three months ago I wrote about getting Carpal Tunnel Syndrome [1]. A few weeks after that I visited the specialist again and had my wrist brace adjusted to make it a little less uncomfortable. The specialist also gave me some quick ultra-sound treatment and then said that if it didn’t get better in a month or two then I should just get a referral to a surgeon!

I didn’t have a bad case, some people have their hand muscles atrophy. My hand strength was measured as 50Kg in my left hand (the one with CTS) and 52Kg in my right hand. The greater strength in my right hand is probably more due to the lack of left-handed tools and sporting equipment than any muscle atrophy. This is slightly better than the physical standards for the Victoria Police (just over 50Kg average for both hands) [2] and a lot better than the Australian Federal Police physical standards of 45Kg for the dominant hand and 40Kg for the non-dominant [3].

Really my hand strength should have been recorded as 490Newton and 510Newton respectively, medicine is the science of healing, in all aspects of science the Newton is the measure of force.

Over the past few months my hand seems to have recovered a lot while wearing the wrist-brace 24*7. I’ve just started going without the wrist-brace during the day and it seems to be OK. I’m currently planning to wear the wrist brace at night for a year or two as it’s the only way to ensure that my hand doesn’t end up on a bad angle when I’m asleep.

At this stage it seems that I’ve made as close to a full recovery from CPS as is possible!

Should Passwords Expire?

June 15, 2010 | etbe

It’s widely regarded that passwords should be changed regularly. The Australian government declared last week the “National Cyber Security Awareness Week” [1] and has published a list of tips for online security which includes “Get a stronger password and change it at least twice a year“.

Can a Password be Semi-Public?

Generally I think of a password as being either secret or broken. If a password is known to someone other than the sysadmin and the user who is authorised to use the account in question then you have potentially already lost all your secret data. If a password is disclosed to an unauthorised person on one occasion then merely changing the password is not going to do any good unless the root cause is addressed, otherwise another anothorised person will probably get the password at some future time.

Hitachi has published a good document covering many issues related to password management [2]. I think it does a reasonable job of making sysadmins aware of some of the issues but there are some things I disagree with. I think it should be used as a list of issues to consider rather than a list of answers. The Hitachi document lists a number of ways that passwords may be compromised and suggests changing them every 60 to 90 days to limit the use of stolen passwords. This seems to imply that a password is something that’s value slowly degrades over time as it’s increasingly exposed.

I think that the right thing to do is to change a password if you suspect that it has been compromised. There’s not much benefit in having a password if it’s going to be known by unauthorised people for 89 days before being changed!

Fundamentally a password is something that can have it’s value rapidly drop to zero without warning. It doesn’t wear out.

Why are terms such as Three Months used for Maximum Password Ages?

The Hitachi document gives some calculations on the probability of a brute-force attack succeeding against a random password with 90 days of attacking at a rate of 100 attempts per second [2]. I think that if a service is run by someone who wouldn’t notice the load of 100 attempts per second then you have bigger security problems than the possibility of passwords being subject to brute-force attacks. Also it’s not uncommon to have policies to lock accounts after as few as three failed login attempts.

Rumor has it that in the early days of computing when the hashed password data was world readable someone calculated that more than 3 months of CPU time on a big computer would be needed to obtain a password by brute-force. But since then the power of individual CPUs has increased dramatically, computers have become cheap enough that anyone can easily gain legal access to dozens of systems and illegal access to a million systems, and it has become a design feature in every OS that hashed passwords are not readable by general users. So the limiting factor is to what degree the server restricts the frequency of password guesses.

I don’t think that specifying the minimum password length and maximum password age based on the fraction of the key space that could be subject to a brute-force attack makes sense.

I don’t think that any attempt to make an industry-wide standard for the frequency of password changes (as the government is trying to do) makes sense.

Can there be a Delay between a Password being Compromised and being Used by an Attacker?

Hypothetically speaking, if a password was likely to be compromised (EG by having the paper it was written on lost or stored insecurely) for some time before an attacker exploited it, then if the password was changed during that time period it could solve the problem. For example when a company moves office there is the possibility of notepaper with passwords to be lost. So if the sysadmin caused every user password to expire at the time of the move then a hostile party would be unable to gain access.

Another possibility is the theft of backup tapes that contain the list of unencrypted passwords. If users change their passwords every three months then the theft of some four month old backup tapes will be less of a problem.

Another possibility concerns the resale of old computers, phones, and other devices that may contain passwords. A reasonably intelligent user won’t sell their old hardware as soon as the replacement device arrives, they will want to use the new device for some time to ensure that it works correctly. If passwords expire during this trial period with the new device then passwords stored in the old device won’t have any value. The down-side to this idea is that people probably sell their old gear fairly quickly and making passwords expire every two weeks would not be accepted well by the users.

It seems to me that having bulk password changes (all passwords for one user or for one company) based on circumstances that lead to potential insecurity would do more good than changing passwords at a fixed schedule.

How are Passwords typically Compromised?

Dinei Florêncio and Cormac Herley of Microsoft Research and Baris Coskun of Brooklyn Polytechnic University wrote a paper titled “Do Strong Web Passwords Accomplish Anything?” [3] which discusses this issue. The first thing that they note is that nowadays passwords are most commonly compromised by phishing and keylogging. In those cases passwords are typically used shortly after they are stolen and the strength of a password never does any good. That paper suggests that banks should use stronger user-names rather than stronger passwords to combat the threat of bulk brute-force attacks.

Can a Password Last Forever?

If a password is entered in a secure manner, authenticated by a secure server, and all network links are encrypted or physically protected then there should never be a need to change it.

Of course nothing is perfectly secure, so for some things with minimal short-term value or which can be used without anyone noticing there is a benefit in changing the password. But in the case of Internet banking if a hostile party gets your login details then you will probably know about it in a few days when the bank calls you about the unusual transactions from foreign countries – long before a 90 day password change schedule would have done any good.

Maybe one of the issues determining whether a password should be changed regularly is whether an attacker could use long-term read-only access to gain some benefit. Being able to read all the email someone received for a year could be a significant benefit if that person was a public figure, and there’s usually no way for an ISP customer to know that someone else is downloading all their mail via POP or IMAP.

Should a Password be the only Authentication Method?

It is generally agreed that an authenitcation method should ideally involve something you have plus something you know. That means a password and a physical device such as a smart card, token with a changing sequential password, or a key such as a Yubikey [4]. If the physical device can’t be cloned (through some combination of technical difficulty and physical access control) then it significantly improves security. When a physical device is used the purpose of the password is merely to stop someone who steals the physical device from being immediately exploit everything – the password only has to be strong enough to keep the accounts secure until a new token can be issued.

The combination of something you have and something you know is very strong. Having a physical token stored on the desk next to the PC that is used for logging in provides a significant benefit, then an attacker needs to break in to the house and can’t sniff the password by compromising the PC remotely.

Conclusion

In all aspects of security you need to consider what threats you face. If an attacker is likely to launch an immediate noisy attack (such as transferring the maximum funds out of an Internet banking account) then changing the password regularly won’t do any good. If a subtle long-term attack is expected then changing the password can do a lot of good – but a physical token is the ideal if the account is valuable enough.

But to put things in to perspective, it’s technically possible to use a mobile phone camera at close range (or a SLR with a big lens at long range) to take a photo of keys that allow reproducing them. But this hasn’t stopped people from carrying their house keys in an obvious manner that permits photography or leaving them on their desk at work. Also I’ve never heard of anyone routinely changing the door locks in case a hostile party might have got a key – although I’m sure that such practices are common in highly secure locations. Few people even take their house keys off the key-ring when they have their car serviced!

Defense in Depth and Sudo – when using sudo can increase security and when it can’t.
Logging Shell Commands – how to log what the sysadmin does and what benefits that provides you, it doesn’t help if the sysadmin is hostile.
Logging in as Root – should you login directly as root?

etbe – Russell Coker

Linux, politics, and other interesting things

Tag Archives: Most Popular

Ethernet Interface Naming

Why Clusters Usually Don’t Work

Buying Suitable Hardware

Testing a Cluster

Running a Cluster

Conclusion

Pre-Meeting Lightning Talks

Creating a SE Linux Chroot environment

Why use a Chroot environment?

The Simplest Solution

Less trusted Chroot environments

SE Linux status in Debian/Squeeze

ffmpeg

dpkg

Policy

Digital Video Cameras

Is Lebara the Cheapest Mobile Phone company in Australia?

Virtual Hosting Prices

Carpal Tunnel – Getting Better

Should Passwords Expire?

Can a Password be Semi-Public?

Why are terms such as Three Months used for Maximum Password Ages?

Can there be a Delay between a Password being Compromised and being Used by an Attacker?

How are Passwords typically Compromised?

Can a Password Last Forever?

Should a Password be the only Authentication Method?

Conclusion

Related Posts