Security > Computer security >
This works, but this topic needs to be better described and hopefully turned into a decent walkthrough.
See also:
-
(date not recorded) - Update: hdparm has lost it's trusted status.
hdparm -Y /dev/hda
as applied just after mounting root (for access to/sbin/hdparm
), has been confirmed to not completely power down a drive on the first pass.hdparm -C /dev/hda
will somehow wake up/dev/hda
. A secondhdparm -Y /dev/hda
appears to properly torpor the drive again. I'm keeping a close eye on this one. Failing to get this to work, removable drives are the next best option. These do exist for ATA133 drives, if you thought they went out with pre 33. Barring that, SCSI still sits there, patiently.
Introduction ∞
This is my little sub-page dealing with my ongoing "securification" project. This is a first draft and feels quite incomplete to me. Perhaps some more solid information on how my own setup is done would help things out. I feel that the basics are reasonably described here, and the real-world examples ought to be generally unnecessary if the background is solid. It's possible to take this project and make an actual distribution out of it, but I feel that an endeavour such as that would be rather fruitless compared to the refinement of the background.
Some History ∞
This line of thinking is heavily influenced by DOS 'easy-install' software, where a program is self-contained within it's own directory. The concept with this is that the user would simply unarchive the files into a directory of their choosing and run it. Software had sane defaults, and the program was entirely self-contained, not caring about where it was installed or where it would save it's configuration options.
I extended this concept by applying it to other programs. Having always maintained an archive of software I liked.. both the software I was using, and software which I had slated to be checked out, I greatly appreciated the "easy to test" software which was self-contained. I found myself doing "pre-setups" for some of my well-loved and frequently-reinstalled software.
I eventually found myself tearing apart Windows 3.1, and later 3.11 for workgroups as well as the 3.11 non-workgroups patch. My desire was to create a roughly pre-setup windows installation which would allow me to simply unarchive the package and use it without bothering to set everything up from scratch. I still have much of this work in an incomplete and unreleased HOWTO I had written and saved.
I despaired when Microsoft effectively "poisoned the well" with Windows 3.1 by removing all support of it and effectively forcing upgrades to Windows 95 through various means. I seriously re-evaluated my use of the Windows operating system, but found myself lacking any real alternatives.
I had real problems with the real and perceived insecurity of Windows, and it's broken defaults. I designed a way of segmenting portions of my computer in the face of having insecure operating systems. What I did was to break apart my use of the computer into cells, each of which may or may not even know the existence of any other part, let alone have actual access.
I accomplished this by creating a pre-installed Windows package with preference defaults of my choosing. It was archived into a package that was kept on a secure portion of the computer, a portion which could not access the archive. I theorized that I could create a "one-time" Windows installation which could be overwritten by my "secure" archive.. thus destroying any real and theoretical elements. Trogans, viruses, locally-stored tracking and such could be wiped out with one simple, thorough procedure.
Simply running a batch file or some software which deletes cookies and such was not thorough enough for my liking. I didn't even like the concept of access timestamps. I had problems with Bad Guys having blanket access to my computer in the ways that I saw possible.
The Contemporary Situation ∞
Nowadays there is a far more clear and present danger in the world. Newer versions of a certain popular operating system are as insecure as ever. Performing security updates (which of course won't be supported on outdated versions) gives the vendor blanket access to one's computer. When one doesn't trust that vendor than there is a serious problem.
At any rate, having dumped the Losedows world for Linux, and having had a couple of years of struggling with it's understanding, I had decided to appeoach this project one final time.
Linux has some abilities unlike anything I had previously known. While it has some extraordinarily embarrassing shortcomings, for this particular project I found it more than adequate. Once again Slackware pulls through with "more magic".
Description ∞
The concept is simple. Create a cell which has sane defaults and useful software which can be destroyed and recreated from scratch in order to entirely undo previous usage. Even if completely compromised, this cell has no access to anything secure. The recreation of the cell is absolute and restores complete functionality.
Two hard drives exist. Let's call them master and slave. The master cell has full and trusted access to the slave cell. The slave cell cannot influence or even see the master cell. Both cells can have quite different setups, even different operating systems. The master cell is limited only in that it has no access to the outside world. The more fundamentally true this is (unplugging cables, removing the network card, etc) the more theoretically safe the entire setup becomes.
These two cells need not be in the same computer, but for this project's purpose they are.
- The computer has a bootup CMOS password, forcing user-interaction to boot.
- The master cell is bootable and controls the bootability of the slave cell via a boot manager.
- The master cell has complete control over the slave cell. The slave cell cannot see or interact with the master cell.
-
Functionality exists to have the master cell push data to the slave cell, overwriting it completely with an assumedly safe and trustable setup.
The Slackware Solution ∞
I have successfully used this securification project on a Slackware master cell and Slackware slave cell. Aside from some dated DOS and Windows knowledge, I am not familiar enough with the functionality of other methods to speak on them.
I created on the master cell a method of shadowing the contents of the slave cell. What I did was create a set of directories referring to each of the partitions on the slave cell. This allows for easy mounting and bulk copying and deletion. Life is made easier for this.
Envision:
mkdir /slave/partition2 mount /dev/hdb2 /slave/partition2
I took this concept far enough that while the slave cell was spilled across six partitions and one supplementary partition, it could be easily backed up from one directory structure within one partition on the master cell. The reverse is true, I could very easily restore the entire directory and partition structure from one single source.
I mount the root partition of the slave cell as slave. Within that partition, it has blank directories referring to it's various partitions. After it has been successfully mounted, I can mount the rest of the partitions associated with the slave cell's drive into that set of subdirectories. What ends up existing is a neat little structure:
/dev/hdb1
on/slave/
/dev/hdb2
on/slave/boot
/dev/hdb2
on/slave/home
/dev/hdb3
on/slave/tmp
/dev/hdb4
on/slave/usr
-
/dev/hdb5
on/slave/var
Now I can do bulk deletes and copies out of slave and have the mounting structure automatically figure out how data should be spilled across the various partitions. Making the partitioning structure more complex changes nothing with the restore or backup scripting.
Let's say I use /slave.backup
as my backup directory. Well, I could do a simple command like
rm -r /slave cp -a /slave.backup/* /slave
.. to restore the backup slave cell from a subdirectory on the master cell.
More intelligent methods of backing up data exist. Intelligent copying exists. Mass archival of partitions is possible, although less flexible for making changes to that structure from the master cell.
Now with this concept in mind, I unplugged my network connection and booted up off my setup CD and installed my operating system across the slave drive. I then booted up into it and set up my preferred packages.. doing the fiddley things which are so much easier to do while actually using the setup to be modified. This is a "sandbox" mode, booting up into a sort of assumed-secure setup on the slave cell to do alterations.
It is fundamentally more secure to never enter a sandbox mode like this, and to make all changes to the slave setup from a remote source.
I then booted back off of the master cell and backed up that slave cell onto the master cell in a subdirectory. This assumes that there is plenty of spare drive space for this use. I can now use the slave cell at will, and recreate it from the master cell whenever I choose. The most secure way of using the slave cell is to recreate it regularly, like before every daily use. Extended use of the slave cell could be insecure in a sense.
Making it work ∞
The fundamentally secure aspect with using the slave cell is with using hdparm. I use
hdparm -Y /dev/hda
.. and force the master drive to power down completely, removing all access from it. Even if the slave cell and hdparm are compromised, they cannot power up the drive without a reboot.
I add hdparm
statements to the bottom of /etc/rc.d/rc.S
to have them start up reasonably early in bootup.
Even if the system is rebooted, the CMOS password forces user interaction.
Even if the CMOS is compromised, the primary drive is booted from and the master drive is the default boot.
The De-Militarized Zone ∞
A slave cell can be recreated and reused, but there is no way to have data persist from one session to the next. A partition in the style of a "demilitarized zone" (DMZ) could be created in order to allow the transference of data between the master and slave cells. This has some fundamental security issues. This sort of functionality would, for example, allow bookmarks, cookies or history lists to persist between recreation sessions. A partition for the slave DMZ and it's backup could be created using the aforementioned method.
/dev/hdb6 /slave.dmz /slave.dmz.backup
The slave cell could just use symbolic linking to files actually held in the DMZ partition as a transparent solution.
A poll of the contents of /slave.dmz
would have to be done in order to determine if it contains any information which should be kept before the slave cell (/slave)
is recreated from /slave.backup
. This step must be done manually and intelligently. This is a hole in the securification setup which allows information to persist between sessions and could allow outside information to persist.
The Stealthed DMZ ∞
Stealthing the DMZ involves making objects on the slave cell transferable to the master cell without leaving any telltale signs. Instead of using a DMZ partition which has a set of files on it which are symbolically linked to on the slave cell, the master cell can have it's own form of linking to secretly label persistent files.
This may be accomplished by creating a set of subdirectories on the master cell, within which are symbolic links pointing to files on the slave cell. While booted into the secure mode, the slave cell can be mounted and exposed to the master cell. One can then choose to selectively transfer those files to the slave cell's backup.. effectively making that set of files persistent between slave cell rebuilds.
Besides being a good idea, this method is required by some software which would overwrite symbolic links with real files. If one were to have, say, configuration files for a piece of software which are actually symbolic links on the mounted DMZ partition, such programs would overwrite them with real files. Lopster is one example of such a program.
A stealthed DMZ could also be made to exist on a subtly removable device, allowing a regular user to insert the removable storage, use it stealthily and remove it right after, shortening the window of opportunity for remote viewing or modification of that data.
Application: ∞
Now that a basic construct of the why and how has been done, perhaps it is best to go into some other applications for this line of thinking.
- The ability to take one setup and spill it across multiple (similar/exact) computers.
-
Internet Cafe - Create a proper setup once, burn the information to one or more CDs (or maybe get into DVD-R). Allow unsupervised and unrestricted floppy access. Give your terminals CD-RW drives.. let customers do whatever they need want.. install software, etc. Basic network security would have to be instituted, and it would be wise to frequently recreate each setup.
Vulnerabilities ∞
Don't consider me paranoid, but overly careful. I've seen enough evidence to suggest much of these items are not only possible but active in the world. These lists are just some notes made to poke holes in the theories of security in this project.
A dirty bootup is a bootup into insecure mode (the outside cell) when that cell has not been recreated first. It is especially dangerous to bounce between insecure and secure modes when the insecure mode is dirty.
Fundamental problems ∞
- Rewriting the slave setup without first retrieving the stealthed DMZ's material results in the loss of that data. Stuff like bookmarks and email are items of note which would find themselves destroyed from such a mistake.
- Pre-existant trojan in the clean setup comes to be used during a sandbox phase.
- The trade-off between automation and manual tasks like auto-logins. Auto-login is inherently insecure, as it requires storing the login information where it might be remotely accessed. Instant messengers, cookies and even a persistent cache could be considered an insecurity by some.
- Snooping and Tracking are still very real possibilities. Data can be 'vulnerable' when passing through ISPs and their transport structures, as well as agents of governments. Email hosts and the hosts of visited websites have similar 'vulnerabilities'.
-
Cookies and various other methods of tracking which use the system as a scratchpad are not delt with via this structure, although their scratchpad is cleared every time the slave cell is rebuilt.
Vulnerabilities due a dirty bootup into insecure mode ∞
- Reliance on hdparm during a possibly insecure bootup phase of the slave cell: A remote hack goes unnoticed and changes hdparm. On next bootup into insecure mode, hdparm is called and instead of powering down the additional hard drives, it alters their content before powering them down as expected, and plants a trojan.
-
If the slave cell is used as a remotely-accessible, development and testing platform, then it is possible that software built on that slave cell could be compromised before being ported to the master cell for use. Splintering the development and testing platform away from a cell which can remotely access services would make things safer.
Local access ∞
- Physical access to the drive. Either accessing it as normal on another setup, or cracking it open to remove and scan the data off of the platters.
- Physical keylogger.
-
Remote screen (or possibly keyboard or other peripheral) scanning to determine their content. See TEMPEST.
Hardware vulnerabilities ∞
- Attacks on the CMOS (not even the main CMOS but others which may exist in controller cards or Network Interface Cards) to change it's code for other purposes (keylogging or other trojans), or to even use it as a temporary storage area. A CMOS attack to remove the bootup password is one example.
-
Drives which automatically keep redundant data for ease of recovery.
- Both Hard Disk Drives (HDDs) and Solid State Drives (SSDs) have additional storage space which is seamlessly used for when the device internally recognizes upcoming problems and silently migrates data. This is done completely without the user's knowledge or permission and the previous marked-unusable spots may have leftover recoverable data.
-
Network Interface Card operation at bootup exposes a vulnerability
- LANDesk Service Agent or other diskless client either functions vulnerably and automatically connecting with full trust to remote services. Pre-existant trojans.
- Network device drivers reuse old frame buffer data to pad packets
"...many Ethernet device drivers fail to pad frames with null bytes. Instead, these device drivers reuse previously transmitted frame data to pad frames smaller than 46 bytes. This constitutes an information leakage vulnerability that may allow remote attackers to harvest potentially sensitive information."
Strange vulnerabilities ∞
- User accidental boot off of a trojan CD or floppy, or use of other insecure and trojan materials. Pre-existant vulnerabilities due to misplaced trust in users, applications or hardware.
- It is an assumption that soft-rebooting clears the memory. There is no guarantee that a reboot cleans the environment entirely. I myself have created RAM drives which have held information beyond a soft reset.
- Destruction of the drive's partitioning table makes restoration less easy.
- Physical effects on hardware, either permanent or merely disruptive.
- It's possible that the cell ought to be recreated regularly.. what if it has a long uptime? Attacks which require time between attempts, or attacks when rely on deposited information could be given an advantage.. in a sense.
- Compromise the CMOS to remove it's password and to have it boot off the slave drive. Rewrite the slave drive to make it bootable. Force a reboot to awaken the master cell.
-
After/while downloading a package on and for the slave cell, a compromised system would allow the tampering of that package. If it is installed during either a secure-slave or sandbox phase, a trojan could be introduced.
Other strangeness ∞
- The Slackware solution rebuilds the slave cell and ultimately mucks up the system time. A solution does exist, but I haven't explored it as yet. Newsreaders can get mucked up when the date/time aren't real.. they inappropriately mark things as new. I think I'll just break down and have the slave cell remotely synchronize it's time somehow or other.
-
It's possible to help securify the slave cell by removing or obfuscating known editors.
Going The Distance ∞
How can this setup be made even more secure?
- Rebuild the kernel: Remove Network Interface Card drivers or modules from the master cell, compile transparent disk-encryption capabilities into the kernel.
- The entire slave cell could be a CD-booting distribution. In fact, many such distributions exist, and allow floppy writes for persistent data. Such systems would be head and shoulders above a project such as this in terms of ease-of-use and perhaps even ease of restoration. This project demonstrates an easily administered and mutable variation on the CD-distribution concept.
- A BIOS or driver-supported "soft read-only" system could be made exist, which allows "writes" to a disk, but actually has them only virtually exist on a RAM drive and throws away that data on reboot.
- Use secure method of deleting and recreating the slave cell. For example, use something like 'shred' instead of 'rm'. Ensure the restoration is as complete as possible. Note that journaling filesystems can interfere with the intentions of a shred-type program.
-
Remove CMOS bootability for floppies, CD-ROMs or other media. Have the bootloader allow the functionality for such bootups, but with securification (either pre-bootup secured logging of some kind, or password protection).
- LILO allows such functionality.
- Physically remove the master cell from outside contact. Perhaps block it off from all use but the controlled-alteration of the clean slave cell.
- Create another cell structure (DMZ) to separate the master cell from the world.
- Physically separate the master and slave cells. Do not have them share any resources.
- Have the communication line between the master and slave cells be dedicated, logged and controlled.
- Physically protect the setup from local access. Lock the case, lock the room etc.
- Add intrusion detection measures. If the measures can't stop intrusion, at least these can be made visible for future securification or even.. retributive purposes.
- Further guarantee security in pulling the slave-cell's sandbox use.
- Further the trust in the hardware. Know it's full specifications. Design and manufacture it oneself.
- Have the hardware unable to boot up any of the cells without outside interference such as with a boot disk, bootable cdrom or a form of dongle. Theoretically it's unsafe to have the boot loading information stored locally. Storing said information on an outside device which requires human interaction would be much safer than a local bootloader.
- Perform a CRC-esque comparison of the CMOS from one bootup to another, to detect interference.
- Other intrusion detection systems (this topic will be extended elsewhere on this wiki at some point).
- TEMPEST shielding.
- Make the slave cell physically read-only (bootable non-RW CD), not via internal or CMOS settings.
- I wonder how useful drive and partition remapping could be.. to obfuscate things a bit more.
-
The slave cell's partitions keep track of the number of mounts, which could be valuable in tracking it's usage.
In Conclusion ∞
Bootup of both the master and slave cell are attended, making a lot of intrusion attempts detectable.
While there is one method which was described, it is the theory of cell-structured and trust setups which one must pay attention to. This knowledge is universal, and many methods can be used to solve the same basic problem: Segmenting untrusted cells and safeguarding master cells from them.
Bootable CD distributions will accomplish what this does.. however it is the theory that I'm interested in. Also, a customized Slackware solution is more useful for me than someone else's setup.
Securification Resources ∞
-
Slackware Administrators Security tool kit (SAStk)
- https://sourceforge.net/projects/sastk/
- https://web.archive.org/web/20041204120354/https://c2i2.com/~dentonj/system-hardening
-- local cache: SAStksystem-hardening.7z - Abandoned
-- their domain is gone and
-- As of 2020-05-31 the sourceforge's last file update was 2002-01-03
-
- local cache: Slackware 8.1 lockdown notes
-
Slackware Tips & Tricks, by Jack S. Lai
- local cache: Slackware Tips & Tricks by Jack S. Lai
-
Linux From Scratch - Secured LFS [ 1 ] was http://hints.linuxfromscratch.org/hints/security.txt
- local cache: Secured LFS.txt
Footnotes
Last updated 2020-05-31 at 18:45:00
ported