SSH port probes and port knocking

On the topic of people receiving unwanted SSH port probes, I have previously posted a script to catch requests and blacklist the source IP's. Though this strategy is effective, it lacks a certain finesse and it also doesn't prevent what I saw as the major problem about such probes - log flooding.

An average Internet-facing server has room for hundreds of megs of logs, an admin capable and willing to go through the logs en-masse and blacklist troublesome IP's. Unfortunately for myself the only real factor in these potential attacks is in the annoyance that a large log or repeated visible attempts generates.

I am always security conscious and this hasn't changed, however I think it's time for my home machine to stop storing logs of every little script-kiddie that pings my port 22 with their tools and instead just ignore them. That was previously much more difficult for me, especially when you see the same IP try and try again. It's just so tempting to blacklist them and imagine their reaction on the other end.

Previous to this article, my port 22 was open to the world (but no other ports). The control of who got in was left in the more-than-capable hands of a religiously updated OpenSSH, with only one working logon allowed to actually come in, passwordless logins denied and a large private-key that's kept secure, protected also by a long random passphrase. That allows access to an extremely limited account whose only purpose is to allow me to su with the right password and become root.

I use SSH to log in from machines when I am at work (where it's incredibly useful to bypass over-zealous school internet filters, with a little help from a proxy on my home machine) and when I need to fix other people's machines. All the schools I work for are NAT'd across the internet through a single IP. Thus, it would be simple to allow SSH through just that IP. However, when I am fixing someone's machine (which could be at a moment's notice), I need SSH to still let me in. This means that I would have a basically random IP trying to connect to my home machine and it would have to deal with it accordingly. This is why my port 22 was left open up until now.

Previously, I just watched the world and his brother bounce standard logins and passwords off of my home machines in a vain attempt to see if I had left some stupid login or password on the machine that might give them some sort of platform to springboard onto higher access. I was secure in the knowledge that not only would they never get the only working account name by bruteforce, nor would they have the publickey and neither would they have the passphrase which went with it. The worst case was that they exploited some kind of flaw in OpenSSH itself which I consider highly unlikely and easily fixable. In that case, it wouldn't be just me who'd be in trouble but half the servers on the Internet and someone would come up with a fix VERY quickly.

These dumb brute-force attacks left a little bit of a bad taste, though. My logs were constantly flooded by "invalid user", "potential break-in attempt" and so on, all through the day. The machine that controls port 22 is a desktop and toy machine, selectively exposed to the internet for convenience and for trying out new systems and therefore it's quite annoying to have logs flooded by such futile attempts at breaking in.

I have put on this blog a script that I used to use, it basically watches the logs via a regular cron job and blocks any IP that tries too often. This works wonderfully and is the situation I would use if I needed random people from random IP's (e.g. employees etc.) to be able to access the SSH on that machine.

Fortunately, I don't need to. The only person to ever use the machine will be myself and therefore it's much easier to me to use port-knocking.

Port-knocking is the Internet equivalent of a secret handshake. As far as anyone on the Internet is concerned the machine is not responding to any connection requests whatsoever. What it is secretly doing, though, is monitoring all such requests for a particular, pre-determined pattern. When it sees that pattern of requests, it modifies the firewall to open a particular port to that particular IP.

For example, it's possible to set it up so that when it sees connection requests on ports 1000, 2000 and then 3000, all from the same IP address, in that order and without any other port requests in between, it opens up port 22 for the IP that tried to connect. Thus, from any computer in the world, I could take a small utility or even just a batch file and a telnet command, hit those secret-handshake ports in the right order and as if by magic SSH would suddenly be available for me to use from that computer.

A similar "knock" of some different ports would also close the SSH port behind me, too. Using this, it's perfectly possible to rap on the internet port of my home computer, get it to let me in, SSH and do whatever I need to do, then rap a different tattoo and it would close SSH. All the time this is happening, every other computer in the world could be trying to get in and all they would see would be a closed or stealthed port (depending on whatever firewall config you have). Being closed or stealthed would also mean that SSH doesn't even have to wake up to deal with such requests, so bypassing any possibility of having some SSH exploit being randomly tried out on the machine. It also means that people can't even GET to the stage where they can try to log in, so instantly cutting out quite a lot of log-spam.

The utility that can knock like this can be as simple as batch or shell script with certain parameters to telnet, to a custom-made tiny C program or a generic port-knocking utility which you supply the port list to. The ports can be UDP or TCP, they can be any numbers in any order, they could even be encoded versions of a particular passphrase or password. Depending on the port-knock listen server in use, the knocks can also be one-time passwords chosen from a predefined list (so that even if someone sniffs your secret-handshake going across the internet, they wouldn't be able to replay it).

I have now switched over to a port-knock system (a good one seems to be Knock from the author of Arch Linux), if only to make my logs easier to read, and have noticed a myriad of advantages from this system.

1) It doesn't make my system any less secure - the only required software is a port-knock daemon that's trivial in implementation and quite secure by design (all it does is listen to connection attempts at the IP level and then extracts the source IP and destination port. It then executes a shell script of your choice which does all the opening, closing of ports etc.)

2) It makes my system more painful for someone unscrupulous to try to access - ports appear closed or non-existent and there is absolutely no indication that anything "strange" is going on. Knock-opened ports are only opened to the IP that knocked correctly, thus keeping everyone else in the world in the dark.

3) It means that the software behind the port-knock is protected from random, "dumb" brute-force attacks and new exploits. Though this isn't 100% effective (as every security analyst has argued when confronted with port-knocking) it's made another step harder, to the point where you really need to be able to sniff all traffic in and out to be able to defeat the simplest configuration of port-knocking. If someone can do that, you're already in trouble.

4) The knock acts as a magic key. It can be a simple numeric list, it can be TCP or UDP or even (theoretically) ICMP. Equally, however, it can be a one-time password that expires after use (so combatting sniffing/replay techniques to open the port), an encrypted sequence, a time-dependant sequence, an IP-dependent sequence, or a combination of those and many other possible sequences (one based on the last time the admin logged in, for example?). Until the magic key is used, nobody can access any port or tell that anything screwy is going on. As far as the casual "hacker" is concerned, there's no way to tell if the machine is switched on and looking for a portknock or switched off entirely.

5) Anybody trying knocks can be blacklisted in a similar way to we had before, but using the failure logs of the portknocker rather than millions of attempts at usernames.

6) The knocks are immune against every-port scans, like an nmap scan, as the knock has to be done in the right sequence. At no point in the sequence is any clue given to a potential brute-forcer about how far through the sequence, which individual knocks were successful etc. because of the multi-stage nature of portknocking.

Knocking port 1000 in the example above makes everything still look closed down. You knock port 1001 afterwards (or indeed any port but 2000) and you have to start the sequence again to be allowed in. However, you get absolutely no feedback about whether or not each stage was successful.

Therefore the chances of brute-forcing the knock have decreased dramatically. Say you have a three-knock TCP-only rule. Then you would have to try EVERY single combination of three numbers all in the range 0-65535. That's 281,462,092,005,375 combinations, over 281 million million, each consisting of a single packet. And in between each one you would have to scan every port to see if it opened anything that wasn't open before. That's going to need a VERY long time and be more than a little obvious, even on the fastest connection in the world.

But now imagine you have mixtures of TCP, UDP and ICMP, four-knock, five-knock etc. rules, time-based rules and other clever trickery to determine what the secret handshake is. It would be all-but impossible, with a decent well-thought out port-knock system, to get anything to open up at all, thus stopping any sort of brute-force attempt before a login dialog had even been found.

7) The minimal overhead of such a system is valuable too. Possible brute-force attackers take no more bandwidth than random port hitters. No resources are required to track hundreds of parallel connections other than standard TCP/IP. The CPU strain is kept to an absolute minimum and the worst case would be a DoS attack requiring substantial resources behind the attackers to initiate. Again, you're already in trouble but at least they're bouncing off your TCP/IP stack rather than trying to guess your passwords.

Multiple parallel attempts from different IP's would be no more help, either. The knock would have to be completed from a single IP correctly. Additionally, it may well be that the knock is IP dependent or that some IP's are blacklisted from any sort of port-knocking anyway!

Additionally, it's one piece of software on the server and one trivial piece of software on your USB key or in your normal remote kit. Currently I always have PuTTY, my private key and TightVNC as my standard remote kit anyway, so adding a tiny portknock utility is a pittance. The system is simple and completely follows TCP/IP rules and standards. To people who are allowed access, the overhead is just one more command, one more password that may even be linked to the main SSH password.

8) The system is completely customisable, from what the port-knock actually consists of down to what it does. In the end, each knock sequence runs a shell script and so can do anything that the user it's running as can do.

9) At the end of the day, even if someone manages to sniff your network, steal the time-dependence equations or even completely guess your port-knocks, you're then left in no less secure a position that you were before. You can still blacklist, you're still password/public-key protected and no changes have to be made to any of the application software either on the client end or server. Everything is just as it was before.


This system is for the ultra-paranoid as well. As an example, consider trying to attack a system with these layers:

1) No ports are opened to anyone without the special knock. The entire world sees nothing but a blank reply, identical to one which a dead connection or turned-off machine would give.
2) The knock is a hash of source IP, time, secret password and other variables. Nobody would see the knock without sniffing every bit of traffic into the computer.
3) Even when the knock is sniffed, replaying it does not open any ports. With no ports open, nobody can attack.
4) Say someone steals the sheet with all the necessary portknock passwords and equations to open the port (an extremely unlikely but yet still not very dangerous scenario).

This is where any open SSH server on the Internet currently is... SSH is considered uncrackable even when all communcation is sniffed if implemented properly.

5) Now they have to find a login that is allowed in via SSH.
6) There are no passwords on any logins, only publickeys, so they also need the publickey of that user (which cannot be sniffed in any way).
7) The publickey is also protected by a passphrase. They now need that as well.
8) They have all the above and managed to get into SSH and login as that user. Now they could (possibly) do some damage by exploiting vulnerabilities in the underlying system.

What would you do if you were faced with such a system? Personally, I think it would be at least 281 million million times easier to just break into the actual building that held that server rather than even try to access it.

But port-knocking is not just for SSH. As hinted above, because the result of a successful port-knock is the execution of a specific shell script, opening holes in a firewall for a particular IP is the most basic of uses. With the right software or hardware it could do anything you wanted. The right port-knock could do anything from turn your machine off to waking up every machine on the LAN, initiating backups to rebooting, putting the kettle on to sending out alerts to every technician.

CCTV, Motion Detection and Linux

Over the summer, I found myself with quite a bit of free time on my hands. I have also, for some time, been eager to install a small CCTV camera at my front door to see who's at the door (Quick, hide behind the sofa!). This is partly for my girlfriend and partly for my gadget obsession.

I read on BBC News and also seperately on The Register about a burglar who was caught when he stole the PC which was monitoring a house's security camera. The PC emailed every image of any movement detected on the camera to a remote email address which, obviously, was quite theftproof.

I thought it was a marvellous idea, having a visual record of any event on a security camera sent to a remote email account (far from where the event is happening and also very secure) which doesn't need any authentication to send to (and therefore leaves no passwords on anything that could be stolen) and also requires authentication (which any intruder/thief could not gain from the computer stolen) to be able to delete/view the images in question. Not only that, but the ISP logs and email images would provide quite substantial legal proof in any case coming to court, in terms of verifying times, dates, tampering etc.

Properly set up, only a pre-emptive phone line cut would be any use against it. Even then, however, there's always the possibility of having a mobile phone,possibly even inside the case of the computer or as one of those PCMCIA GPRS cards, dialling up to an ISP, or even more complicated setups like wireless links between friendly neighbours or to a wireless ISP.

Short of covering from head to toe, cutting the whole neighbourhood's phone lines beforehand (an event certain to attract an unwanted amount of attention), jamming the 2.4GHz that most wireless networks run on and making sure to steal the PC's and any video recording equipment which was running the camera, and then wiping that PC with tools secure enough to obliterate any history of any images being written to the drive, there's not much a burglar could do about sending out some sort of information about themself.

I loved the idea of such a system and also that it actually works in practice, as the above story shows. Some months before this news story I had seen a piece of software that did this and apparently that was the one used to catch this particular burglar. This renewed my interest in Motion.

It didn't hurt that the software was Linux-based, free to use, easy to customise and very powerful. Any camera input (USB webcams, networked or wireless PC-compatible cameras, BT848-based TV cards or, indeed, any video equipment with a Linux BTTV driver) could be fed into the system (in fact many feeds are trivially possible), have complex motion detection algorithms run on it, with still images, short movies and even the audio being recorded whenever motion was detected.

These images and sounds could then be stored, transferred, archived or emailed anywhere (I suppose that FTP or SSH is also easy to do, basically the software writes a JPG/MPG and then runs a shell script of your choice on it whenever it detects motion). Additionally, it would be possible to watch through the cameras at any time by using suitable authentication on the web-based interface, showing real-time images to whatever computer on whichever continent you happen to be.

Over the summer, I invested in a cheap CCTV kit with remote 8" monitor. This monitor could not only supply power to and read video and audio from two different cameras, it would also output one of their composite outputs again without the need for further adaptors or cables. This seemed the perfect setup... a camera wired to the monitor so that I can see what's happening in real time, with the output being simultaneously fed straight into a motion-detecting PC setup.

The setup was a cinch, just a matter of dusting off some WinTV cards and adding one short cable to the CCTV monitor. The software compiled and installed and within about 10 minutes I had it emailing images to an email account whenever my willing volunteer waved their hand across the camera. With some fine-tuning over the next few days of settings and image masks to take care of the timed external lights interfering with the setup, the hanging baskets outside moving in the wind etc. I had the perfect test.

We went to Scotland for a week, leaving the cat at home. We arranged for someone to come feed her during the week and I thought it would be a good test. While we were away, I would dial up to a cheap ISP, log into my home machine and watch the images live. I could also browse through my email account and find all the images of movement. I saw the neighbours walk past at 9.58 a.m. I saw the postman come at 7.00 a.m. and could even see the three items of junk mail in his hands as he walked up to the door. I saw our friend come in to feed the cat as promised. I also got one or two images of a plant pot falling over in the garden.

Now intrigued by the possibilities, I'm considering extending the system. We have a car in the private car park behind the house that can be seen from our spare room. I only wish my neighbours could all have identical systems so that when a car alarm goes off we all know who's it is without leaving the house and can ring up the offender and make them go turn it off!

I plan to install another CCTV camera as a spyhole in the front door to capture full-frontal images of the person approaching the door and maybe as many more as I can find USB webcams for (I know I have at least two lying around). All this and it will cost me a little less than £20 extra per camera to cable and put in an old WinTV card. The computer appears capable of running at least two or three more cameras in terms of CPU speed (motion detection is quite expensive in terms of CPU power) and my test/development machines are old, obsolete things that people were throwing out.

I'm even looking into using a wireless setup so that, for example, the computer running the system could be wired *and* wirelessly connected to my main desktop, other cameras or a second system in a more secure location (the loft seemed an ideal place to run the show from, given that most burglars probably wouldn't bother to go up there).

I also remember having some cards that slot into a computers rear slots and the power supply connectors. They supply 9V outputs on standard connectors that plug straight into most CCTV cameras. With those, I could have a cheap, ancient PC or could even invest in a mini-ITX board, that would be using only a single mains socket and maybe a piece of CAT5. That PC would then be connected directly and supplying power to two or more cameras (some USB, some via PCI TV Card) and even microphones, connecting to a central computer which could store and email the files.

It could even text me the pictures to my mobile or indeed ring me up with an automated message, set off an alarm system, email my neighbours to get them to have a quick look, or blast out MP3's of "Wanted", "Rescue Me" or "Stop in the name of love". It could even display the culprit's face on my home TV in full, glorious technicolour with the words "GOTCHA!" displayed over it, while playing a Wah, Wah, Wah, Wahhhhh sound over the speakers!



What an idea. Marvellous what you can do with technology.

Substrate screensaver

Normally screensavers are disabled the instant I set up a new system and my recent upgrade to Slackware 10.2 was no exception. However, I was looking through the list for a screensaver to test my 3D acceleration to see if my NVidia drivers were working and came across Substrate.

This is a wonderful little screensaver that I find quite beautiful, some say it looks like the evolution of a city from above, others like cracks in a white rock, still others, like a Picasso in progress.

Substrate example images

Either way, it's impressive results from a simple mathematical algorithm. Pity that I can't get a Windows version for my girlfriend as every time the screensaver activates on my machine, she sits and watches it grow.

Edit: I got in contact with the author of a port of XScreensaver, after many, many attempts at trying to find a suitable Win32 version or a version that would compile cleanly under Cygwin or similar environment, and he happened to have a Windows binary of this screensaver just hanging about. So thanks Darren Stone for your help! The version of WinXScreenSaver on his software page didn't have it when I tried but he pointed me to a version of just that screensaver that he had compiled some time ago: http://tron.lir.dk/software/w_substrate.zip

(As of late-February 2008, the above website appears to be down. For now, there is a mirror of this file here: http://www.ledow.org.uk/windows/w_substrate.zip

Another Linux Desktop Update (and Slackware 10.2)

The Linux desktop machine is not only still going well, but getting better all the time. In fact, Windows has been deleted from my main computer, the result I'd been hoping for and something I'd been wanting to do for years. As far as I'm concerned, Windows in all it's variations is now just another console, good for games, not much use for anything else.

I recently upgraded to Slackware 10.2 on my main computer. Generally my computer is usually near the most updated you can get without having Beta or Alpha or CVS-build software on a machine. When it comes to upgrades, I upgrade to the next version of software depending on:

1) Whether I can run it in tandem with the older version - While this is possible with most things (e.g. Opera, PuTTY, TightVNC), it's not always possible with major upgrades. I want to KNOW that I can run the new version but that if there is a single regression I can still use the version I was using before.

2) Whether I can always revert to the older version if I want - This is where a package management system beats the built-in Windows features hands down. Not only will Swaret find, download, install and check dependencies of any software I install using it, it will also make a backup of the previous version. A simple removepkg/installpkg will get me right back to where I wanted, at worst having to replace any tailored config files from a personal backup. Most Linux distributions have such facilities, RPM, DEB, etc.

3) Other people's experiences of upgrading to that software - Lots of confirmed reports found on Google, relevant forums etc. of no major problems is the best thing, lack of any reports of major problems is next best. The less information available, the less I trust the upgrade.

4) Reputation of and previous experience installing that software - a program which has never had an install problem, upgrades itself neatly and compactly, is able to import all of its old settings etc. is one I'm more likely to upgrade as soon as I can.

5) The severity of the upgrade - how important an upgrade it is will determine how quickly I will be upgrading to it. Serious security updates for critical flaws and serious bug fixes for dangerous bugs will be more likely to be installed that something that corrects a spelling mistake in a filename.

6) The enormity of the upgrade - minor upgrades are more likely to occur, major upgrades may be postponed until I can test them out fully.

Given the above, a Slackware 10.1 -> Slackware 10.2 upgrade snags on 4,5 and 6. Numbers 1 and 2 are dependent on how carefully I think through the upgrade, and information for 3 wasn't available, although many people have been running the slackware-current version between the 10.1 and 10.2 release (I hereby thank all the willing testers for ensuring my machine will be relatively safe by the time 10.2 comes out).

Security wasn't a major problem - I was properly firewalled, my common desktop software (Opera etc.) was always at the latest stable version and nothing exposed to the internet was vulnerable. There were a few upgrades I was looking forward to, most notably a Ghostscript upgrade that made my printer (a Samsung ML-4500... possibly the only laser printer I've ever seen that you can open the specially-designed toner cartridge and just pour in certain toner without having to re-buy the entire cartridge) work much better under CUPS.

KDE upgrades were also on my agenda but not something I was happy attempting on my primary desktop machine by myself. This fixed things like my icons jitting about the place between (fairly infrequent) reboots, konqueror crashing while navigating the filesystem and numerous other little niggles.

It turned out in the end that I managed to clear out my old 10Gb Windows partition (so there really is no going back now!), after throwing a few lifebelts to things like documents, INI files and other stuff that might come in handy someday. With Slackware, unlike Windows, I literally formatted the drive as ext3 and copied the old Slackware install over using cp -a -x to the blank drive. This copied all the files, links, etc. over without modifying them.

A small oversight discovered later was that the -x (stay on a single filesystem) for some reason excluded /dev but even *that* couldn't stop Linux trying it's best to boot (although a lot of drivers complained). That went into the rather short list of "Should I ever have to do this again, remember to"'s.

Once the filesystem was copied across, I booted from a boot disk making sure that the new partition was the linux root. I played with the lilo config to set it up (keeping some older entries to boot back into the original config should I ever need to), edited fstab and then reinstalled lilo.

[[ Side note: My favourite thing about Linux in general is that any kernel can boot any partition on any computer. I needn't have bothered with this backwards compatibility entries in lilo, I could have just booted from any Slackware boot CD that I had laying around and tell it which partition to use as root and I can fix/run anything to get it back up and working.]]

Then I booted into this identical copy of my root and only once I was in and everything was working as if it was my old drive did I follow through the Slackware 10.1 -> 10.2 UPGRADE.TXT instructions.

The upgrade went very smoothly and once the package upgrades were complete, it was merely a matter of setting up lilo again to boot from the 10.2 2.6.13 generic kernel that had been installed (making my own initrd on the way) and then rebooting.

[[side note: Although I think that initrd are a marvellous idea (a small mid-boot ramdisk environment to bung in any strange drivers that may be needed at boot time, e.g. USB/Firewire Mass Storage, SCSI etc.) they can be a pain in the backside when you just want to add a new line to lilo with a slightly different config. That usually means rebuilding the initrd with different root parameters etc. which soon can become a file-management nightmare, having to keep kernels, configs and initrds for every different combination. Hell... it works and you can tweak it to do some complicated stuff, so I'll suffer it.]]

After that, it was simply a matter of seeing what needed recompiling to fit in with the numerous upgrades that were in 10.2 (kernel, KDE, QT, libraries etc.). I didn't even bother to check whether the proprietry NVidia drivers I use (the only low-level non-source-code thing I have installed on this machine) would need recompiling as I was certain they would. This went without a hitch and then I was able to boot into X-Windows on this new system and "see what else had broke".

That turned out to be the driver for my never-used wireless card (which is used for purely experimental purposes as I don't generally trust wireless in any way shape or form, ever since I demonstrated to myself just how easy it is to crack WEP and really interfere with most wireless networks whatever the encryption... the only access allowed over the wireless interface is a public-key authenticated SSH). That caused me some minor problems as it was complaining about the module config of the kernel (a missing file normally attributed to having kernel source lying around which didn't actually compile the kernel in question). This turned out to be a bit of a false alarm as the module would load normally anyway and worked perfectly.

Other than minor issues and a bit of user stupidity, there were no problems. Strange, for an upgrade that's the equivalent of going from Windows 95 to 98, or NT4 to 2000, that there was so little upheaval and virtually zero compatibility problems. And yet, my primary partition was never in any danger and with a small boot from the CD and a tiny LILO tweak, I'd have been back as if I'd never touched the machine.

I have now also tried Knoppix 4.0 on my laptop, similarly impressed that it needs absolutely no prior knowledge of what system it's going to run on. I'm amazed at just how much of the stuff that I have bought or been given "just works" in Linux, at worst requiring me to hunt down a small GPL driver from somewhere:

The QX3 microscope I found at a boot sale.
A cheapy PSX->PC USB controller adaptor (though games are not the focus on this machine, it was just out of interest).
A cheapy USB hard drive enclosure, again found at a boot sale.
My Intel NetportExpress (from eBay) connected so that myself and my girlfriend can stop fighting over who gets to use what printer.
My cheapy graphics tablet that was bought on a whim and never really used

Admittedly, some things I deliberately research to ensure they work on both operating systems; my wireless card, my USB key, my cheapy, ancient printer, my sound card (went through two or three old, donated and junked sound cards which, while they all worked under Linux, all showed performance problems. In the end, I just bought a cheapy SoundBlaster Live off eBay to save me having to use software mixing).

I always knew that Linux had problems with certain pieces of hardware, back from when I first heard about Linux when I was just a lad. Now I think that 99% of the problems are sorted out and most systems "just work". Heck, even most winmodems can be persuaded to work in Linux, even if they do need a binary driver. So far, the only thing I've found that remains resolutely incompatible with Linux is a small USB-IrDA adaptor that was never bought to work with Linux and, though it's detected as a serial port, doesn't actually support all the IR protocols that it would under Windows.

Addendum: And now I'm being asked to install Linux systems for an unattended kiosk-style system and a few small specialised workstations running the QX3's inside some of the schools.

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.