Encrypted File Systems
Find a couple of blank floppies on which to test an encrypted file system. Then, create an encrypted file system using DES encryption:
# dd if=/dev/urandom of=/dev/fd0 bs=1k count=1440 # losetup -e des /dev/loop0 /dev/fd0 Pass phrase: des test # mke2fs /dev/loop0 # losetup -d /dev/loop0
A couple of notes about this example:
The first command initializes the floppy disk with random data. Initializing the disk to zeroed data reduces a blank disk to a “known plaintext” cryptology problem—not a good idea.
The second command specifies that we want a loopback device to cover the floppy device driver with a DES encryption layer. We could replace /dev/fd0 with the name of a file. The pass phrase is not echoed. Also, the pass phrase can be 120 characters long—and should definitely be more than 8 characters!
The third command is the normal mkfs(1) utility.
The fourth command releases the loopback device.
Finally, create one more pair of disks which use different passwords. (If you want to be unusually perverse, use your previous IDEA test pass phrase on your second DES test disk and vice versa.)
Now we're ready to mount these disks. First, try to mount the floppies using a standard mount command:
# mount /dev/fd0 /mnt -text2
These commands should fail with “can't find an EXT2 file system.” Now try mounting each floppy again:
# mount /dev/fd0 /mnt -text2,loop,encryption=idea # mount /dev/fd0 /mnt -text2,loop,encryption=desIn each case you should be prompted for a pass phrase. Needless to say, you should not be able to mount the DES encrypted disk when specifying IDEA encryption, and vice versa. Likewise, you should not be able to mount the DES encrypted disk 1 with the second password or vice versa, and you should be able to mount the file system when you specify the correct encryption format and password.
This is another area where gremlins have appeared on my system. Once IDEA encryption worked fine but /dev/urandom failed; in another case, /dev/urandom worked but IDEA encryption produced kernel warnings on every even sector.
Now a few more tests. Edit the /etc/fstab file to add these entries:
/dev/fd0 /mnt/des ext2 defaults,noauto,loop,encryption=des 0 0 /dev/fd0 /mnt/idea ext2 defaults,noauto,loop,encryption=idea 0 0
Try to mount your test disks on /mnt/des and /mnt/idea. Once again you should be prompted for a pass phrase and will be successful only when encryption algorithm and pass phrases match.
Finally, reboot your system and repeat these tests. If possible, install the modified kernel on a second system and verify that you can exchange media between the systems. Such is life on the bleeding edge of technology.
Now that we have encrypted file systems, what can we do?
We can add strong encryption to programs which don't support them natively, and we keep their files on an encrypted file system.
We can add strong encryption to distributed media. Some people already build ISO-9660 images in a file via a loopback device; producing an encrypted image would be trivial.
CD-ROM-based back-up protocols become more attractive. Outdated back-up discs can be discarded without fear of a dumpster diver gaining access to crucial information.
We can improve system security. Programs such as Tripwire, which record cryptographic signatures of key files, traditionally require read-only media to prevent attackers from modifying the reference information. It is still conceivable that an inside attacker could replace this critical disk. Now, we can easily keep this crucial information in an encrypted form, making a spoofed disk much harder to produce.
We can add a measure of strong encryption to entire systems which don't support them natively. Encrypted file systems should be exportable via NFS or SMB—packet sniffers remain a problem but the disk would be protected.
Even taking a cursory glance at the trends of security software, one notices recurring themes. Encrypted file systems protect the data on disks. SSH (Secure Shell) encrypts and authenticates communications. Secure-RPC (remote procedure call) encrypts interprocess communications. RPM authenticates software upgrades.
Is there any question that encryption and authentication routines belong in the kernel? Encryption keys could be stored with each device and process, and with negotiations for unique session keys automatically mediated between any process within and without the system that desired it. There would not be needless duplication of identical routines, or worries about export restrictions since these issues would have already been addressed. If necessary the encryption routines could be localized to a loadable module, although that raises certain security issues.
The downside is anyone with root access can grab the encryption keys from the system tables; however, once root is compromised all bets are off anyway. On the other hand, supplying strong encryption and authentication services in the kernel should reduce the risk of root becoming compromised. Also, DH key negotiation means that my keys aren't compromised even if I'm talking to someone who is compromised.
Bear Giles firstname.lastname@example.org, of Coyote Song LLC, is a UNIX Consultant with almost 15 years of experience. He has used Linux at home since pre-0.99 days.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space