Security in the file system
"Invisible" file backups could be used which only the system would be able to access, they would never be presented to applications. Only the user via the system would be able to manipulate them (i.e. to delete confidential data). A full OS backup could exist like this so if an attacker manages to circumvent the controls preventing them from changing system files, the system would detect the difference and replace the changed file with the correct one. The invisible OS backup files should not be presented to anyone, not even the user.
Code level security
Another method of improving security is to improve the code in the system, audit [Audit] the code for errors and bad code. Better code means less bugs and less bugs means the system is more stable and more secure.
Another method of improving security is to enforce correctness in either the language itself or at runtime. Some programming languages make it easy to write insecure code [BadCode] but one method of improving it is to add additional modules at compile or run time which check the program as it runs. Perl already does this in it's "Taint" [Taint] mode but it may also be possible in languages like C [Code].
These techniques could be taken further - if libraries include potentially bad functions why not remove them and replace them so they are not in the system API. Scan executables for dubious function calls, if they are present refuse to run that software. It'll make porting software a royal pain in the arse but software will be better for it.
Trying to modify and existing system to accommodate such a level of security will not be easy and liable to break applications and irritate users. This is one of the benefits of starting anew since there is nobody to annoy. It will be interesting to watch the reaction of the market to Service Pack 2 for Windows XP.
Security is a difficult subject but by restricting the system defaults like this and making a paranoid system which is constantly checking itself and everything coming in will make life more difficult for attackers. Locking the system down from unnecessary changes and keeping the bugs to a minimum means security is built right into the system, it's not added after the fact where it can never be as effective. It also works, OpenBSD [OpenBSD] have been using this philosophy and at least some of these techniques for years.
Of course power users will not like a system like this but there's no reason why controls could not be added to allow developers and power users more access to and control of the system.
The File System
Of course for our new platform we should have the best file system we can build. It should ideally have some of the following features / functionality:
- 64 bit
- Journaled
- Non fragmentory
- Automatic analysis and identification of files
- Arbitrary metadata for files with indexing to facilitate high speed searching
- Support for "live" searches - that is it should monitor the file system for changes and tell interested applications about the changes
This may sound like a radically advanced file system, but I have just described the file system "BFS" which was introduced to the world in BeOS. There's a great hullaballoo about OS X "Tiger" adding search technology and Windows Longhorn using a database as a file system (an approach Be tried and later abandoned due to low performance). This is another example of existing technology spreading through the industry [Indexing] even if it's old news to some of us!
I don't however think that Be or BeOS users ever fully utilised the capabilities of BFS and in that respect support for it's capabilities could be better integrated into the system. The apparently very similar technology in OS X Tiger looks like it'll be a lot more integrated and thus useful to the end user.
Gnome Storage [Storage] wants to go further and translate files when storing them so you can read them with different programs without needing to support different formats. Similar functionality was available with Datatypes on the Amiga and Translators in BeOS though these were used by applications directly. I'm not sure if I like the idea of doing this as part of the file system as it'll add a performance impact every time something is read / written and the use of XML means conversions to / from non-linear structures, computers are inherently bad at dealing with these in an efficient manner (throwing a faster CPU at it will not help, it's a memory latency problem).
Search: Finding it better
If I've just downloaded pictures from a USB stick and want to edit them I have to either find then and activate the editor or, run the editor and manually find them with the file requester. This could be made easier by adding a few buttons to the file requester which use search functionality, press "latest files" and they'll just appear. You would never need to go looking for files again.
Of course this wont work for everything, in order for metadata to properly work it needs to be added to the files and there are limits to how much of this can be done automatically. Adding metadata will need to be done at least partially manually and that becomes a user interface issue. Nobody is going to add metadata to every file so a window could appear with a set of options to help this process, the context will be important as well as the type of file in deciding which options. Past actions could also be analysed so the system can guess and present options based on those.
This need not be as complex as it sounds, if I download an image it can give me options of Astronomy, Humour, Technical, Cool, Geeky, Personal etc. If it's really clever it can look at the originating web site and give a guess - i.e. anything from NASA is likely to be in the Astronomy category (this would require the web browser to store the URL as metadata with the downloaded image).
Metadata can also be potentially be used for all sorts of other not so obvious things. If you are running a second OS as this system allows, it will expect files in certain places. Your file system layout may not be in agreement with this alternative i.e. you may not want to add a new partition to your Hard Disc. You could use metadata to create a virtual file system, write the desired path as metadata but put the file in a directory for the second OS's files. When the second OS wants a file the file system it gets the file from this directory by looking for a file with that piece of metadata.
This has interesting security possibilities as the second OS will not be reading directories directly so even if it tries asking for something else it will never get anywhere as there will be no other files with the correct metadata.
You could also create a file system layout from metadata by doing the above in reverse. We could do the same with normal metadata, to go back to my downloads example lets say I've saved a few humour and astronomy images in my downloads directory. A single command could move them to the right place - i.e. home/nick/pictures/humour or home/nick/pictures/astronomy.
I'd like to see other functions added to the file system such as automatic backups, a technique which has been used on big iron for years. Again metadata could help out here - store the backups in another location with the original path in metadata. This would save having your directories have multiple copies of each file and rapidly becoming unreadable.
Searching could also be enhanced by storing parts of files in metadata. The system could search for files containing specific strings but look in the metadata index first for speed (Apple is doing this in Tiger).
- "Security and Files, Page 1/3"
- "Security and Files, Page 2/3"
- "Security and Files, Page 3/3"
