Security is a mindset, rather than any single action

My opinion. Swill it around a bit … do you agree?

Layers and lack of control:

A new starter is given access to live servers and asked to code up some simple shell scripts, to automate a bit of hosting setup and/or cron tasks.


Not having deep experience with Ubuntu Servers, the new starter immediately dives in and tries to write scripts that use the extended (non posix) features of the bash login shell.

Bash Arrays or let count=count+1 are examples.

So the task progresses and the bashisms are in.

Another task is taken on and completed again using bash extensions similar to those mentioned above.

Now another administrator is asked to add those tasks to a daemon process or startup script.

But the scripts don’t work!

Hacker Solution: Change the default system shell from /bin/dash to /bin/bash

task1, task2, ..., use in daemon/cron

What is highlighted in Red are the human failings.

The creation of a daemon process / cron should not trigger a policy change on a server.

There are several good reasons why Ubuntu switched to dash as the default shell over 5 years ago.

From my personal point of view, bash is too complex, and is better suited to the task of a ‘login shell’ rather than a ‘system shell’ / ‘process shell’

The more complex a piece of software…

  • the more likely a new security hole can be found
  • the more likely a move of versions will result in breakage

The phrase “Keep it simple stupid” feel appropriate here.

Human failings – how could this happen?

The intricacies of posix standard shell scripts are not the first thing a new Linux System Administrator will learn.

Should they be? Well that depends on whether you see certification as important

Pushing your new Linux System Administrator to become Red Hat (RHCE) certified, is one way of introducing them to standards and the context of operational tasks

Here is an unofficial introduction to the sort of thing that RHCE might expect.

How many years into Linux System Administration should the Administrator know about the Single Unix Specification? It all depends on your organisation and how you wish to operate.

In most organisations, the implementation of a new daemon / startup task could never trigger a policy change at the server level.

Some organisations that have no firm security policies and no configuration management documentation, might well fail to stop the actions accompanied by red indicators in my diagram.

This is an organisational / human failing and has nothing to do with the specifics of the technology. It could interchangeably be Linux, or Solaris, or Windows that lacked the human controls to prevent such a change.

Bash is secure – it is rare that there are any new exploits:

Bash changes infrequently (which is good), and most exploits in the last 10 years have been around insecure temporary file creation.

That does not mean that using a non-interactive shell (/bin/dash) is unnecessary, if you need interactive features and feel lost without non-posix bashisms, then do use bash as your login shell.

From experience, the folks who use the more intricate / esoteric features of bash, are usually lacking in knowledge of sed / awk / python.

Using bash to do serious scripting (string processing in particular) is not too different than, using a hammer to knock in a screw. It’ll work, but there are better tools for the job.

Links and Further Reading:


It is a good discipline to read machine logfiles periodically and be on the lookout for messages that stand out.

One recent linux message that might start appearing on a Linux 64 bit machine concerns HPET ( High Precision Event Timer ) and here is an example:

CE: hpet increasing min_delta_ns to 15000 nsec

Now running off and web searching for results is probably a longer way round than reading the next paragraph or two, which have the important things you might want to know first.

Firstly this is a Linux kernel feature designed to help power efficiency so on the whole it is a positive thing.

It is neither brand new nor some serious bug.

It can be disabled if you are bored of reading about it already ( hpet=disable )

There is an Intel presentation titled ‘Getting maximum mileage out of tickless’ which has on page 3 a gentle introduction to why hpet is a desirable feature.

For the more technically adept there are some further details here and here.

Back to the message I was seeing in my logs…there are bug reports regarding messages of the sort 'hpet increasing min_delta_ns', in particular, if you are seeing lots of these messages in your logs, then it might be worthwhile engaging with the kernel development team and sharing your output.

For me this laptop install is a brand new Xubuntu 64 bit install and is still in the process of being fully configured. When I have all my applications running as I wish then I’ll check the logs again and see if things look okay. With just a single message appearing occasionally, it might be that waiting a few months for the Lucid upgrade is (and the newer kernel 2.6.32) will be the path of least effort.

For folks running Debian / Ubuntu servers in the cloud, this information regarding tickless might be worth a read.