Oct 032015
 

More up to date information can be found here.

One thing that has always puzzled me about Linux Containers was why it is necessary to configure the network address in two places – the container configuration, and the operating system configuration. The short answer is that it isn’t.

If you configure network addresses statically within the container configuration :-

» grep net /var/lib/lxc/mango/config 
# networking
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.ipv4 = 10.0.0.35/16
lxc.network.ipv4.gateway = 10.0.0.1
lxc.network.ipv6 =         2001:0db8:ca2c:dead:0000:0000:0000:000a/64
lxc.network.ipv6.gateway = 2001:0db8:ca2c:dead:0000:0000:0000:0001

Then the configuration within the container’s operating system can simply be :-

» cat /var/lib/lxc/mango/rootfs/etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
iface eth0 inet6 manual

And that works fine.

Oct 032015
 

A newer post has more information (and more reliable information).

One of the things that has been mildly irritating me about my little collection of Linux containers has been that in addition to the statically defined IPv6 addresses, there is also an automatically defined IPv6 address :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                                                              AUTOSTART  
---------------------------------------------------------------------------------------------------------
apricot   RUNNING  10.0.0.34  2001:db8:ca2c:dead:21e:a0ff:feb6:6a, 2001:db8:ca2c:dead::3eb      YES        
chagers   RUNNING  10.0.0.32  2001:db8:ca2c:dead:804a:bfff:fe83:f98d, 2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  10.0.0.31  2001:db8:ca2c:dead:21e:a0ff:feb6:66, 2001:db8:ca2c:dead::ba11     YES        
lyme      RUNNING  10.0.0.30  2001:db8:ca2c:dead:21e:a0ff:feb6:65, 2001:db8:ca2c:dead::cafe     YES        
mango     RUNNING  10.0.0.35  2001:db8:ca2c:dead:6c42:24ff:fe7d:4e9, 2001:db8:ca2c:dead::a      YES        
peach     RUNNING  10.0.0.33  2001:db8:ca2c:dead:21e:a0ff:feb6:68, 2001:db8:ca2c:dead::3a11     YES        
rhubarb   RUNNING  10.0.0.40  2001:db8:ca2c:dead:21e:a0ff:feb6:69, 2001:db8:ca2c:dead::dead     YES

Now this is hardly the end of the world, but it is not tidy and it is the sort of thing that may lead to problems down the road if servers are communicating on an address that is not reverse DNS registered. Or indeed when someone contacts a server on an address such as 2001:db8:ca2c:dead::3eb and the reply comes from 2001:db8:ca2c:dead:21e:a0ff:feb6:6a.

After any number of false starts, the answer is quite simple – use sysctl to turn off autoconfigured address from within the container; which doesn’t make much sense logically – containers don’t have a kernel of their own, so the global kernel should be the one that is tuned. However :-

for container in $(lxc-ls)
do
  echo net.ipv6.conf.eth0.autoconf = 0 >> /var/lib/lxc/$container/rootfs/etc/sysctl.conf
done

Does the trick (after a reboot)  :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                                                              AUTOSTART  
---------------------------------------------------------------------------------------------------------
apricot   RUNNING  10.0.0.34  2001:db8:ca2c:dead:21e:a0ff:feb6:6a, 2001:db8:ca2c:dead::3eb      YES        
chagers   RUNNING  10.0.0.32  2001:db8:ca2c:dead:18d9:99ff:fe28:3591, 2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  10.0.0.31  2001:db8:ca2c:dead:21e:a0ff:feb6:66, 2001:db8:ca2c:dead::ba11     YES        
lyme      RUNNING  10.0.0.30  2001:db8:ca2c:dead::cafe                                          YES        
mango     RUNNING  10.0.0.35  2001:db8:ca2c:dead:2411:80ff:feb9:6600, 2001:db8:ca2c:dead::a     YES        
peach     RUNNING  10.0.0.33  2001:db8:ca2c:dead::3a11                                          YES        
rhubarb   RUNNING  10.0.0.40  2001:db8:ca2c:dead::dead                                          YES        

Except for the older containers 🙁

I’ve obviously missed something, but fixing nearly half of the containers is a good start.

After attending to pending upgrades (some of my old containers were still running wheezy), and setting the network configuration to manual, one of the recalictrant containers (glanders) lost it’s autoconfigured address.

Two more containers lost their unwanted extra addresses after “fixing” their configuration. I’m not sure what was wrong with the old configuration, but after copying and modifying a recently created container configuration, they rebooted with just one IPv6 address. The last one was mango, but after an extra reboot, it also was fixed :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                      AUTOSTART  
-----------------------------------------------------------------
apricot   RUNNING  10.0.0.34  2001:db8:ca2c:dead::3eb   YES        
chagers   RUNNING  10.0.0.32  2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  10.0.0.31  2001:db8:ca2c:dead::ba11  YES        
lyme      RUNNING  10.0.0.30  2001:db8:ca2c:dead::cafe  YES        
mango     RUNNING  10.0.0.35  2001:db8:ca2c:dead::a     YES        
peach     RUNNING  10.0.0.33  2001:db8:ca2c:dead::3a11  YES        
rhubarb   RUNNING  10.0.0.40  2001:db8:ca2c:dead::dead  YES        
Sep 242015
 

2015-09-24 19.02.32

Your new phone turned up on my desk today. It's all very sparkly but there is one big problem with it.

The name.

If you are going to release a product named with an English-language word, then you may want to check the spelling of that word because spelling that word wrong is not very impressive.

Now Americans would have you believe that the word is spelt as you have spelled it – honor. However there is a clue to the originators of the language in the name; you should the spelling with the English.

If you ever release a version of the phone in North America, it would be reasonable to use their spelling of the word. But elsewhere in the world, please use the correct spelling.

It's a bit over the top to insist on a product recall for this, but please remember when it comes to releasing the next version of this phone that it should be called the "Honour 8".

Sep 222015
 

So it looks like Volkswagen has been fixing emissions testing in the US …

220px-Volkswagen_logo_2012.svg

It seems that they have probably built into the engine management software something that detects when the engine is being tested for emissions. This apparently detects testing conditions and switches to a test mode where the engine power is reduced sufficiently to reduce emissions below the legal limit. Real emissions are up to 40 times the legal limit.

Volkswagen are apparently very sorry about this, but probably more about being caught than anything else. It could be just a one-off aberation, but frankly it is more believable that this sort of thing only happens within a company that has a culture where deceiving the customers and regulatory authorities is seen as perfectly acceptable practice.

So what else are they up to?

In a Science Fiction story by Charles Stross (Halting State), auditors do a much more thorough job of checking companies for ethical behaviour and screening executives for sociopathic tendencies; Volkswagon's path out of this mess involves and up close and personal relationship with a savage group of auditors looking into the ethics of the company. 

But who else is using engines that lie to emissions tests? Not only do many other car manufacturers use Volkswagen engines, but other car manufacurers also have an incentive to do the same sort of thing. How much do we trust them?

How many Volkswagen engineers and managers involved in this "special" project have gone on to work for other manufacturers?

Sep 122015
 

According to the latest advice from CESG: "Regular password changing harms rather than improves security, so avoid placing this burden on users."

Wrong!

(Thanks to xkcd.com).

Most of the advice given is eminently sensible, and indeed forcing password changes on a frequent basis does more harm than good – when forced to change their passwords every 30 days (yes really!), people will commonly resort to sanity and use passwords of the form: someword-${month} (such as "happy-July"). However the advice to never force password changes was obviously written by someone who is under the belief that staff accounts have a somewhat limited lifetime – people change jobs, etc.

There is still a great deal to be said for changing passwords less frequently – say every couple of years. Or even a random number of days between 730 and 1,095, which will help to randomise calls to the Helpdesk. Amongst other things :-

  1. The concept of a strong password changes over the decades; allowing account passwords to remain the same for the lifetime of a staff account will mean that a considerable number of staff accounts will have weak passwords.
  2. There is such a thing as "accidental shoulder surfing" whereby someone acquires knowledge of part of your password by merely being present when you enter it. Over time they can acquire more and more of your password. 
  3. Only changing an account password when there is a suspicion it has become compromised means that there is no mechanism to lock stealthy intruders out. Whatever kind of anomolous account behaviour detection mechanism you have in place, there is always the chance that a compromised account can remain below the radar; periodic password changes do lock this intruder out.
  4. Less directly, but forcing regular account password changes on an infrequent basis does have the side effect that it allows the education of people that passwords can be compromised.

Of course every security person who read the CESG advice on passwords probably thought "Great. Now who is going to educate the auditors?".