The perfect operating system

As in other articles, this list will grow as I think of new stuff to add to it.

--- Software for the operating system will come as a single, standardised file. This file will be openly-readable by a suitable viewer/editor and be appropriately compressed.

--- Upon installation, each piece of software will be confined to it's own folder/directory within a system-wide software repository and not need to access anything outside that directory. Requests for system-wide configuration changes, such as file associations, notification of events, binding to internet ports etc. will be indicated by a specially-named file within a specially-named subfolder of the software.

These files are seen by the OS as **requests** for configuration changes. The OS will handle detecting these files and allowing the user to choose which piece of software gets to ACTUALLY change the system in the way it asks for. Facilities would be included to specifically BLOCK individual programs from requesting such changes, if necessary (to avoid spamming the user with bogus requests). Any changes in these files are notified to the user concerned to allow them to decide what to do.

--- No piece of software will be allowed any sort of access to another piece of software's folder. Each piece of software has a folder which will have it's own subfolders, each with a unique cryptographic hash stored for the purposes of detecting changes.

These subfolders will include: Programs (for the program's executables and required libraries), Configuration (for program-wide configuration information and system-wide configuration requests) and Data (for additional data, such as user-created documents, frequently updated databases, temporary files etc.).

--- The OS will control software and the movement of data. Each user will have the same program folders present (although those seen by the users will depend on their security permissions) and each user can have their own unique configuration for each program (again, security policy allowing).

The OS will determine which user the software is running under and create links to the correct configuration for that user. This will be under a copy-on-write basis, with new users getting the basic system install and each user's changes stored seperately. Any unchanged files will use the system's defaults.

Similarly for data, each user will have their own data directory for each piece of software.

The OS will also be responsible for detecting shared libraries between software (using name, internal information such as company, version number etc., cryptographics hashes and so on). Common libraries will be detected by the OS and links created to a system-wide libraries directory, after gaining permission from a suitable user to do so.

--- There will be OS facilities for users to transfer data from one piece of software to the other, but programs will NOT be able to do this themselves as they will NOT be able to access any other software's folder. Ideally, these mechanisms will be transparent and a user will see a "Home" folder which contains all of their data files from every program. These will be links to invidual files within a software's Data directories.

The user is free to arrange their Home folder how they wish... links will stay intact, unneeded files will be hidden from view. By selecting a file, they are able to open it in the software in which it is currently residing or in another suitable piece of software. The OS will handle multiple programs opening the same file in the same way as current OS's use hard links, that is the file is only present ONCE but it's entry may appear in multiple software Data directories. The OS will only show a single copy of any file in the user's Home directory, though. Once a non-default program has finished with a certain item of data, the link is removed from it's Home directory, unless there is no other link to that file.

--- As part of the "file presence" system-wide configuration request mechanism, programs may request the use of specialised libraries and other programs. If granted (either by security policy or by appropriate user permission), the software is allowed read and execute access to that program, it's configuration and it's associated data, again taking account of the user it is running under.

--- Uninstallation of software is as simple as removing it's folder or moving it outside of the software repository. Orphaned configurations/data would remain present in each user's Home directory.

--- The OS will provide a security facility for all password/passkey entry. Whenever a password/key needs to be entered, the user will select the password/key field in the softare requesting it. Upon this selection, the OS will clear the screen and place a special, unfakeable, unchangeable indicator in a position on the screen.

While the system password screen is active, no other program may display any component of itself onscreen and all drawing requests are done off-screen. No other piece of software will be able to overlay or display this indicator but the OS itself. When this indicator is lit, all input device control is passed to the OS but NO OTHER PROGRAMS. The password is entered by the user (or the file/device necessary is selected), then sent directly to the software which provided the initial password/key field.

Additionally, the system security screen will clearly show the name of the software initiating the request for a password/key, the reason for it's request and any username or other information required to provide the correct password/key.

Rules for software

A list of things that every piece of computer software do. This list will grow as and when I think of stuff to add to it.

1) Context-sensitive help (such as the "What's This" style help), if implemented, should be defined for EVERY button/option, in much the same way as every single image on a website should have an ALT tag.

2) All software should include an "uninstall" option, whether by an operating-system-provided mechanism or by a simple program supplied with the software. The uninstall should NOT require a reboot (except on those OS's where it's the only way to do it), should kill any running instances of any part of the software, clean up after itself (removing itself and the directories it was contained in) and ask the user if they want to remove configuration information for the program, save games, other files it finds in it's install directories, etc.

If the user does choose to keep this information, it should be put into a directory of the user's choice, labelled by default with the name of the software. This information should include any and all registry entries and, at the user's option, removing or reverting back any file association changes etc. that were made by the software.

3) If a program requires a certain file, library, etc. it should explicitly check for it at install time and run time. If any required file isn't found at any time, a check should be made for all required files and a list printed of the files the program needs in order to run. Lower-numbered versions of required files are seen as incompatible and will make the software print the file AND version required. Websites and other sources of these files should be displayed if known.

4) New versions of a program should ALWAYS come with a small utility or facility within the program itself to convert an installation of an older version into a format compatible with the new version. Hence, older config files are translated into any required new format automatically by the software to the equivalent or a safer configuration. These "convertors" should always be run whenever a previous installation has been detected and should be installed no matter what. Users should be informed by the software of any regressions in new configurations.

5) ALL software should co-exist with ANY version of itself without conflicts. On installation, it should not overwrite any previous installation unless asked to although it may steal, for example, file associations from it's previous versions.

6) Any installation changes with system-wide effect must gain the approval of the user before they are executed and provide an option to skip that step. Unless absolutely critical to the running of the program, the software should run whether the users chooses Yes or No. This covers file association changes, default printer changes, URL handler changes, default action changes (such as auto-insertion of audio CD's etc.) and similar measures.

Electronics

One of my interests has always been computers and I've always known the basic theory about how computers work, how the electronics operate etc. I know how electronic components work and what each does and even the formulae that are relevant but I've never been confident enough to actually dive in and start creating stuff from scratch.

I enjoy the Velleman kits from Maplins... ten minutes with a soldering iron and you have an electronic game or quiz buzzer or clock, but I could never follow how they worked properly. There was always some strange arrangement of components that confused me.

Recently, I was asked by my brother to make a little "disarming" pack for his Scout group for a camp they are going on. I made him one a few years ago that was basically a small circuit with no electronic components that the Scouts had to "disarm" without setting it off. It consisted of a buzzer and a battery. The buzzer was constantly short-circuited by a small resistor on a wire that stopped it sounding. When the wire was cut or the resistor removed, the short circuit disappeared and the buzzer sounded.

That was crude and simple and didn't really work very well apparently, and I was also concerned about how safe it was so had to test it a lot. A few weeks ago, my brother announced that he wants another one and I had enough warning this time to do it properly.

I found the Kelsey Park Electronics Club website, belonging to a school many miles from myself, and it's been a lifesaver, explaining things that I've never seen explained anywhere else, in a simple way, with lovely printable PDF's for the projecta. The author clearly knows his subject and it is a fantastic resource.

Using that website, analysing a few of the circuits and stealing a few of the ideas from there I've come up with a brilliant circuit for this year's camp and have already spent a small fortune at Maplin's buying the breadboards and components and testing it out. Now, if only I could find a louder but lower-power buzzer than the one that cost me a tenner!

Another Linux Desktop progress update

It's been over a month and I'm sticking with Linux on the desktop. Too many things "just work" for me to go back, my data actually feels more secure than it did before and the computer does what I ask of it, poorly written software aside.

What poorly written software? Nothing too vital. I just wanted to play some movie trailers online with Opera but that's proving almost impossible, even with MPlayer-plugin, plugger et al. Nothing seems to make it work whereas FireFox runs it just as it should with the same plugins.
I've followed every page I could find on getting these plugins to work with Opera but they just display a blank box or throw up lots of stdout errors, or both. That's no big deal, I could just use Firefox, but I like the way Opera works faster for day-to-day browsing and is integrated with RSS, news, mail, etc.

The other program that was giving me hell was KPlayer. Some files it just would not display properly, displaying what appeared to be vsync problems (a single tear at a certain point on the screen while displaying video). I first noticed this while playing a DVD. Putting KPlayer into X11 rather than XV mode solved it but it took too much CPU. MPlayer GUI showed no such problems (despite KPlayer using MPlayer to display) but I didn't like it or any of it's skins.

I could NOT find any difference between how KPlayer and MPlayer were rendering the clips but KPlayer always looked different. Eventually, Xine came as a good middle ground, showing all the clips I want it to while not displaying any artifacts, using the computer's hardware acceleration to it's full and having a usable GUI.

Using ALSA-only for sound is a great leap forward and the only problems I get are the soundcard-sharing issues that are well documented and easy to fix with dmix plugins. I've tried those and they work perfectly.

I investigated KDE 3.4 for a while, even downloading the KLAX live CD (a new version of KDE on a SLAX LiveCD, based on Slackware). 3.4 seemed faster, more responsive, cleaner and more bug-free but I'm wary of upgrading it until I've made a tar.gz of my system as it is at the moment. That's another thing that I love about Linux... the low-level config is all runtime-determined and the remaining config is hardware-independent.

I can transfer this disk image to any other machine in the world and it would boot up (after running lilo) and work just as before, with only a few minor tweaks to support non-detected hardware. The point is that, unlike Windows, I could move this hard disk to any machine should this one go wrong and be up and running again in minutes rather than hours and use the exact same settings as I have now. You just CANNOT do that with Windows. Even changing your motherboard pretty much requires a reinstall but in Linux, it hardly cares about what motherboard you are running.

I've gone onto Linux 2.6 now, given the fact that it supports more hardware, has ALSA built-in at the kernel level, has lots of bugfixes and new features. It meant that I had to tweak the startup scripts somewhat to enable me to dual boot and compile software for whatever kernel I happened to be running (mainly just symlink magic) but that didn't take long and was hardly necessary anyway... I think I've only booted back into 2.4 once.

KNemo has replaced my Zonealarm because now I have the power of an iptables firewall, I just miss the little flashing lights that indicated network activity. :-)

SSH logins are now working flawlessly and, following advice from a number of sites, I've got non-root passwordless SSH up and running, with an su providing all the power I need. I do see this as a little unnecessary root had his own private key that was the only way to log in but it's working now. I can use PuTTY from work and log in to my home machine and laugh at all the login attempts I see bouncing off port 22:

203.73.40.40 only tried 2 times.
210.96.200.24 only tried 2 times.
212.19.84.19 only tried 2 times.
210.204.129.27 only tried 3 times.
211.160.17.13 only tried 3 times.
212.160.93.188 already blocked for 5 attempts.
61.16.165.148 already blocked for 5 attempts.
70.183.189.207 already blocked for 5 attempts.
210.178.215.221 already blocked for 6 attempts.
211.169.117.119 already blocked for 6 attempts.
211.248.77.194 already blocked for 6 attempts.
213.179.250.115 already blocked for 6 attempts.
218.108.89.205 already blocked for 6 attempts.
61.219.67.127 already blocked for 6 attempts.
66.14.195.102 already blocked for 6 attempts.
202.180.175.138 already blocked for 7 attempts.
61.218.8.110 already blocked for 7 attempts.
202.127.24.198 already blocked for 8 attempts.
211.112.77.28 already blocked for 9 attempts.
211.114.170.161 already blocked for 9 attempts.
203.199.69.160 already blocked for 10 attempts.
201.144.107.203 already blocked for 11 attempts.
213.21.187.186 already blocked for 11 attempts.
202.141.12.146 already blocked for 12 attempts.
84.45.142.57 already blocked for 12 attempts.
220.65.55.130 already blocked for 13 attempts.
202.201.0.246 already blocked for 15 attempts.
210.51.12.238 already blocked for 15 attempts.
211.114.177.138 already blocked for 15 attempts.
211.114.195.7 already blocked for 15 attempts.
62.76.207.201 already blocked for 15 attempts.
163.27.7.2 already blocked for 18 attempts.
81.190.223.110 already blocked for 21 attempts.
64.49.222.180 already blocked for 24 attempts.
222.53.117.195 already blocked for 28 attempts.
210.51.25.217 already blocked for 32 attempts.
202.183.229.200 already blocked for 34 attempts.
66.82.4.25 already blocked for 39 attempts.
211.147.7.88 already blocked for 43 attempts.
212.89.111.97 already blocked for 44 attempts.
62.65.85.126 already blocked for 44 attempts.
81.214.131.217 already blocked for 44 attempts.
61.220.76.58 already blocked for 57 attempts.
220.130.3.60 already blocked for 61 attempts.
212.251.61.243 already blocked for 77 attempts.
211.250.189.5 already blocked for 89 attempts.
217.160.130.112 already blocked for 89 attempts.
24.10.130.62 already blocked for 89 attempts.
80.190.249.210 already blocked for 89 attempts.
82.235.174.242 already blocked for 89 attempts.
12.26.192.66 already blocked for 108 attempts.
165.229.65.86 already blocked for 108 attempts.
64.208.57.92 already blocked for 108 attempts.
81.208.31.177 already blocked for 109 attempts.
203.177.36.178 already blocked for 114 attempts.
80.183.225.131 already blocked for 122 attempts.
219.101.165.151 already blocked for 154 attempts.
195.70.198.199 already blocked for 216 attempts.
66.236.248.139 already blocked for 216 attempts.
211.26.36.3 already blocked for 221 attempts.
128.252.171.31 already blocked for 348 attempts.
211.172.225.111 already blocked for 382 attempts.
211.144.101.203 already blocked for 413 attempts.
61.193.182.107 already blocked for 425 attempts.
218.149.85.18 already blocked for 467 attempts.
202.30.198.245 already blocked for 519 attempts.
137.195.182.25 already blocked for 701 attempts.
213.251.132.146 already blocked for 702 attempts.
218.179.255.249 already blocked for 1409 attempts.

That's the output from my custom script which I add new features to whenever I feel like it:

#!/bin/sh
#
# Script to search logs for SSH brute-force attempts and block IP's

# Log a message saying we have started.
logger -t SearchLogs -p cron.notice -- Starting Log Search...

# Search through /var/log/messsages for "Failed" lines from SSH.
# Strip out IP from each line.
cat /var/log/messages* |grep sshd |grep Failed\ password\ for | sed s/.*from\ // | sed s/\:\:ffff\:// |sed s/\ port\ .*// > /tmp/ssh_attempt_ips.txt

# Similarly for "Invalid" lines
cat /var/log/messages* |grep sshd |grep Invalid\ user | sed s/.*from\ // |sed s/\:\:ffff\:// >> /tmp/ssh_attempt_ips.txt

# Similarly for "Did not recieved identification string" lines
cat /var/log/messages* |grep sshd |grep Did\ not\ receive\ identification\ string\ from | sed s/.*from\ // |sed s/\:\:ffff\:// >> /tmp/ssh_attempt_ips.txt

# Sort IP's and weed out any duplicate lines to rid us of multiple IP's.
# Also, add a count of each IP so that we can judge how many attempts
# they had and strip out some whitespace.
#
# Also, ignore any line containing 212.85.1.15 as that's our main IP for
# logging in from, similarly for 127.0.0.1.
cat /tmp/ssh_attempt_ips.txt |sort |uniq -c -d |sort |sed s/\ */\ / | sed '/.*212.85.1.15/d' | sed '/.*127.0.0.1/d' > /tmp/ssh_attempt_counts.txt

# Remove whitespace from beginning of line, place | in between counts and IP's.
cat /tmp/ssh_attempt_counts.txt |sed s/\^\ // | sed s/\ /\|/ > /tmp/ssh_prioritised_list.txt

if [ -f /tmp/ssh_prioritised_list.txt ]
then
# For each line...
for BAD_IP in `cat /tmp/ssh_prioritised_list.txt`
do
# Strip the count from the IP...
COUNT=`cat /tmp/ssh_prioritised_list.txt |grep $BAD_IP | sed s/\|.*//`
IP_TO_BLOCK=`cat /tmp/ssh_prioritised_list.txt |grep $BAD_IP | sed s/.*\|//`

# If a particular IP had more than 5 goes...
if [ "$COUNT" -gt "4" ]
then
EXISTING_LINE=`iptables -n -L INPUT |grep $IP_TO_BLOCK`

# Add to permanent blacklist.
echo $IP_TO_BLOCK >> /etc/ssh_blacklist.txt

# If it's not already on the firewall blocklist
if [ -z "$EXISTING_LINE" ]
then
# Print out a message and add to firewall.
echo Blocking $IP_TO_BLOCK for $COUNT attempts
logger -t SearchLogs -p cron.notice -- Blocking $IP_TO_BLOCK for $COUNT attempts
logger -t SearchLogs -- Blocking $IP_TO_BLOCK for $COUNT attempts
echo iptables -A INPUT -s $IP_TO_BLOCK -j DROP
iptables -A INPUT -s $IP_TO_BLOCK -j LOG
iptables -A INPUT -s $IP_TO_BLOCK -j DROP
else
echo $IP_TO_BLOCK already blocked for $COUNT attempts.
logger -t SearchLogs -p cron.notice -- $IP_TO_BLOCK already blocked for $COUNT attempts
fi
else
# Just warn.
logger -t SearchLogs -p cron.notice -- $IP_TO_BLOCK only tried $COUNT times.
echo $IP_TO_BLOCK only tried $COUNT times.
fi
done
else
echo "Can't read /tmp/ssh_prioritised_list.txt"
fi

cat /etc/ssh_blacklist.txt |sort |uniq > /tmp/ssh_blacklist.txt
cp /tmp/ssh_blacklist.txt /etc/

# Log a message to say we've finished
logger -t SearchLogs -p cron.notice -- Log Search Ended.

#---------------------------------------

I have that running as a cron job and it produces the output you see above. It's amazing how many attempts you get. Looking up the IP's on DShield shows that I'm not alone on being attacked from some of these IP's. It's tempting to move the SSH port just to avoid the log spam.

Overall, thoroughly impressed. I wouldn't class it as a perfect system but it's a damn sight closer than Windows ever was and when you consider that people who are giving their time and effort away are doing a better job than the largest company in the world pumping billions into research, you have to ask yourself whether you've ever been right to give them money.

Some computer annoyances.

I've had a few pet peeves about how computers work for many years and I thought I'd air them here. Firstly, login procedures.

Why are password dialogs not more secure? How many times have you had some program pop up and ask you for a password while you are in the middle of typing, you've not noticed and pressed some keys and Enter in the course of your work? Or how many times have you been in the middle of writing a password when something else pops up or shifts the cursor focus so you end up typing the password somewhere completely different? (Hotmail's login dialog comes to mind because sometimes it would change focus if you typed in your password before the scripts on the page had finished loading, meaning you typed your password on the login name box for all to read).

In the same way that Windows has the "press Ctrl-Alt-Del" to log on, in order to ensure that your password can only go to the one program not affected by Ctrl-Alt-Del, i.e. the login dialog, shouldn't we have some facility within the OS itself to prevent other passwords being scattered willy-nilly when they are entered?

Maybe a system-default password screen. If the user needs to enter a password for any purpose, they have to click on the password box itself, which is just a large rectangular link. When that is clicked, the screen is blanked, the keyboard is locked to every program but the login system (so preventing software key-loggers) and a password dialog appears asking you to "Type in the password for Opera 8.01 to access the website www.hotmail.com" or "Type in the password for Control Panel to access your network configuration" or "Type in the password for SSH to login as the user root on remote system server.house.com".

This screen would also be secured by the operating system somehow, to ensure fake screens could not be generated (even though they would require user-interaction to do so). This could be by some sort of visual cue which cannot be modified or overlaid by any program by the system itself (in a similar vein to the secure icon in web browser which SHOULD NOT be able to have a website overlay it's image) or by using the clever tricks that people are suggesting web browsers should use such as a customised screen which nobody but the system has access to... therefore the program would have to know what the user's customised login screen looked like. Any deviation from their picture of The Simpsons beating up a computer and the user would know that it was a fake login box.

[Incidentally, I once used a technique many years ago, before the web was popular, to obtain an admin login at my old school. Using Visual Basic and the PrintScreen button, I was able to replicate the look and functionality of the RM software login screen that the school was using at the time, even down to the help dialogs and pixel-perfect positioning, and got my sixth-form computer science teacher to log into the machine. It was set up so that it failed consistently with any login but wrote the username and password to a file.

The computers at the time had a problem that they would fail to log in with the exact same message if they had been disconnected from the network since they booted up, no matter if you reconnected them later on. The way to fix it was to reboot from the login screen. My program simulated this functionality and was run from within any non-privileged user account. Once the admin had typed their username and password, they got the error they thought meant the computer had to be rebooted, they would reboot, come to a GENUINE login screen and log in successfully. However, the username and password they had tried would be logged to a plaintext file on the user account I had run the program on.

Honestly, I let the person in question log in, then immediately told him what I'd done. Stupidly, he had challenged everyone in the sixth form to try to get admin access, seeing it as a learning experience, and had foiled several previous attempts to steal his username and password. The only other success was when someone read his password over his shoulder and then created dozens of admin accounts using it, using their own name. They were quickly spotted and caught. Mine wasn't and would never have been as multiple logins from the same username were allowed and I would have had time enough to circumvent the measures in place which showed up admin users on the system (an easily subvertible two-line "cron job" that showed all admin users on a spare monitor in the server room)]

Ideally, there would be a fourth LED on your keyboard, indicating "secure" status which can ONLY be toggled by the operating system itself, not application software or device drivers. This would light only when the REAL login screen was up and people would be trained to realise that if the light's not on, people can read their password.

This should also stop the problem of accidentally writing your password at the end of the username box. Either a special button or key combination (even as simple as tabbing to the password field in question and pressing enter) would take you to the secure password screen. The light on the keyboard would be enough to show non-touch-typists that they are in the password box, the blanked screen for the login procedure enough to show touch-typists that they are in the right place.

I do consider password showing on the screen to be quite a weak link, though not completely unstoppable. For a busy user, though, especially around kids or teenagers, this would be a great way to stop unintentional password theft.