"The Linux Gazette...making Linux just a little more fun!"

Crypto Support for Linux

From dreamwvr, August sometime in 1998 (in an old thread on the Linux-Admin List which I've been reading as part of the research for my book).

i believe it is called efs which stands for encrypted file system...

Glynn Clements wrote:
There is Matt Blaze's CFS (cryptogrphic filesystem) which is basically a userspace filesytem over NFS to the loopback interface. This was part of a larger package called ESM, encrypted session manager. That wasn't Linux specific, but does work under it.

Joseph Martin wrote:
I am helping a friend set up a new computer system. He is particularly interested in security. The regular linux authentication at the console should work well enough, however I was wondering about even more security. Are there any encrypted file systems we could set up? For example the computer boots up, loads the system from a ext2 partition and then presents a login prompt. After login a mount command is given, a password supplied and the partition data made visible and acessable. After use of partition it is unmounted and rendered unusuable again. Anything like that exist?

You can use the loop device, which turns a file into a device which can then be mounted (assuming that it contains a valid filesystem).

The loop device supports on-the-fly encryption/decryption using DES or IDEA (but you have to get the appropriate kernel source files separately; they aren't part of the standard kernel source due to legal nonsense).

Alternatively, you can just encrypt the file with any encryption package (e.g. PGP), and decrypt it before mounting. However, this requires sufficient disk space to store two copies of the file.

Glynn Clements

There is also the TCFS --- a transparent CFS from Italy. This is Linux specific code. (https://tcfs.dia.unisa.it)

There was also supposed to be a userfs module for encryption --- but I don't know if that was ever completed to production quality.

The best place to get most crypto code is to just fetch it from ftp://ftp.replay.com (or https://www.replay.com) which is located offshore (Netherlands?) to put it beyond the jurisdiction of my government's inane trade regulations. (Apologies to the free world).

I thought I read on the kernel list that https://www.kerneli.org was supposed to be a site where international (non-U.S. exportable) patches would be gathered and made available. However that address only returns a lame one line piece of text to lynx. I fared better with their ftp site at:

ftp://ftp.kerneli.org/pub/Linux/kerneli/v2.1

Where I saw a list of files of the form: patch-int-2.1.* (which I presume are "international" patches).

Userspace toys can be found in:

ftp://ftp.kerneli.org/pub/Linux/redhat-contrib/hacktic/i386

(RPM format, of course).

Meanwhile the loopfs encryption module seems to be located at Linux Mama (canonical home of unofficial Linux kernel patches)

https://www.linuxmama.com/dev-server.html

which has a link to:

ftp://fractal.mta.ca/pub/crypto/aem

TCFS is also suitable for encrytion of files on an NFS server (only the encrypted blocks traverse your network --- the client system does the decryption. That's a big win for security and performance).

As for encryption of other network protocols: There's the standard ssh, ssltelnet/sslftp (SSLeay), STEL, suite for applications layer work, and a couple of IPSec projects for Linux at the network/transport layer. A friend of mine has been deeply interested in the FreeS/WAN project at:

https://www.xs4all.nl/~freeswan

... or at:

https://www.flora.org/freeswan

(a mirror)

... This consists of a kernel patch and some programs to manage the creation of keys etc.

The idea of the FreeS/WAN project is to provide opportunistic host-to-host encryption at the TCP/IP layer. In other words my Linux router would automatically attempt to create a secure context (tunnel/route) when communicating with your IPSec enabled system or router. Similar projects are underway for FreeBSD, a few routers like Cisco, and even NT.

Anyway I haven't tried it recently but I hear that it's almost ready for prime time.

One of the big issues is that FreeS/WAN isn't designed for manual VPN use --- so it's command line utilities for testing this are pretty crude (or were, last time I tried them). On the other hand we still don't have wide deployment of Secure-DNS --- which is necessary before we can trust those DNS "KEY" RR's. So, for now, all FreeS/WAN and other S/WAN secure contexts involve some other (non-transparent) key management hackery.

Hopefully someone will at least create a fairly simple front end script for those of us that want to "just put up a secure link" between ourselves and a remote office or "stategic business partner."

Also FreeS/WAN has focused it's effort on the 2.0.x kernels. When 2.2 ships there will be another, non-trivial, effort required to adapt the KLIPS (kernel level IP security?) code to the new TCP/IP stack. The addition of LSF (linux socket facility --- a BPF-like interface) should make that easier --- but it still sounds like it will be a pain.

There's apparently also an independent implementation of IPSec for Linux from University of Arizona (Mason Katz).

https://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html

... however this doesn't seem to offer any of the crypto code, even through some sort of hoops (like MIT's "prove-you're-a-U.S.-citizen/resident" stuff). I've copied Mason on this (Bcc) so he can comment if he chooses. I've also copied Kevin Fenzi and Dave Wreski in case they want to incorporate any of these links into their Linux Security HOWTO.

https://sunsite.unc.edu/LDP/HOWTO/mini/VPN.html
https://sunsite.unc.edu/LDP/HOWTO/Security-HOWTO.html

An alternative to FreeS/WAN for now is to use VPS https://www.strongcrypto.com with 'ssh' This basically creates a pppd "tunnel" over a specially conditioned ssh connection. You have to get your copy of 'ssh' from some other site, for the usual reasons.

Yet another alternative to these is CIPE (cryptographic IP encapsulation?) at:

https://sites.inka.de/sites/bigred/devel/cipe.html

... which used encrypted UDP as the main transport.

Of course we shouldn't forget our venerable old three head dog of mythic fame: Kerberos. This old dog is voted most likely to be our future authentication and encryption infrastructure (if for no other reason than the fact that Microsoft has vowed to "embrace and extent" --- e.g. "engulf and extinguish" it with Windows NT v5.02000).

The canonical web page for MIT Kerberos seems to be at:

https://web.mit.edu/kerberos/www

... some news on that front is that Kermit version 6.1 is slated to include support for Kerberos authentication and encryption. More on that is on their web site:

https://www.columbia.edu/kermit/ck61.html

... on the international front I hope to see the Heimdal project (from Sweden) reach production quality very soon.

https://www.pdc.kth.se/heimdal

When I talked to a couple of the developers of Heimdal I asked some hard questions about things like support SOCKS proxy (by their Kerberized clients), and support for one-time-passwords, support for NIS/NIS+ (nameservices lookups), etc. They seemed to have all the right answers on all counts.

All that and it's free.

Another European effort that is not nearly as attractive to us "free software fanatics" is the SESAME project (Secure European System for Applications in a Multi-vendor Environment)

https://www.esat.kuleuven.ac.be/cosic/sesame

The SESAME license only allows for free "experimental" use --- no free distribution, no installation for customers, and no "production use." Worse than all that no indication is made as to how much licensing would cost (say for individual use by a consultant). It appears to be geared towards limited distribution to "big" clients (the owners seem to be Bull SA, of France).

However, they have some interesting ideas and their web pages are well worth reading. The suite of libraries seems to offer some worthwhile extensions over Kerberos.

Some other pointers to cryptographic software are at Tatu Ylonen's (author of ssh) pages:

https://www.cs.hut.fi/crypto/software.html

(I've also copied Arpad Magosanyi, author of the VPN mini-HOWTO, in the hopes that he can find the time to integrate some of these notes into his HOWTO --- perhaps just as a list of references to other packages near the end).

Of course the main thrust of Linux security has nothing to do with cryptography. An over-riding concern is that any privileged process might be subverted to take over the whole system.

Bugs in imapd, in.popd, mountd, etc. continue to plague Linux admins.

If security is really your friend's top interest and concern, and he's planning on running a general purpose Unix system with a mixture of common daemons (network services) and applications on it. I'd really have to recommend OpenBSD https://www.openbsd.org. That is considered by many to be the most secure "out of the box" version of Unix available to the general market today. (In the realm of commercial Unix, I've heard good things about BSDI/OS (https://www.bsdi.com).

That is not to say that Linux is hopeless. Alan Cox has been co-ordinating a major Linux Security Audit project at

https://www.eds.org/audit

or:

https://lwn.net/980806/a/secfaq.html

There's also a set of "Secure Linux kernel patches" by Solar Designer (I don't know his conventional name --- everyone on the lists refers to him by this handle).

https://www.false.com/security/linux/index.html

These are a set of patches that prevent a couple of the most common sorts of exploits (buffer overflows and symlinks in /tmp and other world-writable directories).

However, these patches are for 2.0.x kernels. They've been firmly rejected by Linus for inclusion into future kernels in favor of a more flexible and general (and more complicated) approach.

Linux version 2.2 will support a "capabilities lists" (privileges) feature. This splits the SUID 'root' mechanism into a few dozen separate privileged operations. By default the system maps 'root' and 'SUID root' to setting all of these privileges as "enabled" and "inheritable." A sysctl() call allows a program to blank some or all of these bits, preventing it and (if one is clearing the "inheritable" bits) all of its descendants (all the processes it creates) from exercising these operations.

This should allow us to emulate the BSD securelevel if we want to (create a little userspace utility that clears the appropriate "inheritable" bits and then exec()'s 'init' --- now all processes are unable to perform these operations).

It's also nice in that it's more flexible than the BSD 'securelevel' feature. For example you could just strip the privilege bits from 'inetd' and your various networking daemons. This would mean that the attacker would have to trick some console/serial line controlled process into executing any exploit code.

The eventual plan is to add support for the additional bits in the filesystem. That won't happen for 2.2 --- but will likely be one of the planned project for 2.3. These filesystem attributes would be like a whole vector of SUID like bits --- each enabling one privilege. So each program that you'd currently make SUID 'root' would get a (hopefully) small subset of the privileges. If that sounds complicated and big --- then you understand. This is essentially what the MLS/CMW "B2-level" secure versions of commercial Unix do. (As described in the TCSEC "orange book" from what I hear).

As a stopgap measure I hope that someone writes a wrapper utility that allows me (as an admin) to "manually" start programs with a limited set of privileges. This would allow me to write scripts, started as 'root' that would strip all unnecessary privs, and exec some other program (such as 'dump' or 'sendmail' or 'imapd' etc). (Such a wrapper would also allow a developer or distribution maintainer to easily test what privs a particular package really needed to work).

So, that's an overview of the Linux crypto and security. There are just too many web resources on this subject to list them all, and there is obviously plenty of work being done on this all the time. The major constraint on any new security work is the need to support Unix and all the existing and portable Unix/Linux packages.

Crypto Support ... What Book?

From Dave Wreski on Mon, 09 Nov 1998

(From an old thread on the Linux-Admin List which I've been reading as part of the research for my book).

Hey Jim. I was just wondering what kind of book you are writing? Is this a linux-specific security book?

Dave

Linux Systems Administration (for Macmillan Computer Publishing https://www.mcp.com).

Since I consider security to permeate all aspects of systems administration, there will be quite a bit of that interwined with my discussions of requirements analysis, recovery and capacity planning, maintenance and automation etc.

FS Security using Linux

From AZ75 on Tue, 10 Nov 1998

Hello, My name is Jim Xxxxxx and I am a US citizen. I would like have a copy of the crypto code sent to me for testing if that's posible. I am at: ....

I think you misunderstand part of this thread.

I wrote an article (posted to the Linux-admin mailing list and copied to my editors at the Linux Gazette, and to a couple of involved parties and HOWTO authors). In that article I referred to the work of Mason Katz.

Mason wrote one of the two implementation of IPSec for Linux. Please go to

https://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html

... and take particular note of this:

You may request the export controlled sections by sending email to mjk@cs.arizona.edu

... at the bottom.

Also, if you read the notes more thoroughly, you'll find a comment that:

Although we are not currently tracking the IPSEC architecture, we believe that the released version can be brought up to date and extended to allow for more services.

... which means that this implementation is probably out of sync with recent revisions to IPSec. That means that coding work would have to be done to make it interoperable with other implementations.

I think you'd be far better off with the Linux FreeS/WAN implementation. In that case you'll be importing the code from the Netherlands. The stated goal of the Linux FreeS/WAN project is to provide a fully interoperable, standard implementation of IPSec.

I still don't know what they're going to do about key management and Secure-DNS. I can't pretend to have sorted out the morass of competing key management specifications: Photuris, ISAKMP/Oakley, SKIP, IKE, etc. The Pluto utility with FreeS/WAN implements some sort of IKE with ISAKMP for part of the job (router-to-router mutual authentication?). The OpenBSD IPSec uses Photuris --- and I don't know of a Linux port of that. Presumably an interested party in some free country could port the OpenBSD Photuris to use the same interfaces to FreeS/WAN's KLIPS (kernel level IP security) as Pluto. My guess is that the two key management protocols could work concurrently (your FreeS/WAN host could concievably establish SA -- security associations -- with IKE hosts through Pluto and with Photuris hosts) although I don't know how each end would know which key management protocol to use.

I came across one reference to an alleged free implementation of Sun's SKIP for Linux in an online back issue of UnixReview Magazine (now called Performance Computing). That made a passing references with no URL.

Further Yahoo! searches dug up Robert Muchsel's:

https://www.tik.ee.ethz.ch/~skip

... which leads to a frames site (Yuck!). However, the recent versions of Lynx can get one past that to more useful page at:

https://www.tik.ee.ethz.ch/~skip/UsersGuide.html

I also guess that FreeBSD offers a SKIP enabled IPSec/IPv6 implementation out of Japan through the KAME project at:

https://www.kame.net

Anyway, for now it appears that most of the key management will have to be done by hand (using shared secrets which are exchanged using PGP, GNU Privacy Guard, or over 'ssh' or 'psst' (GPG is the GNU re-implementation of PGP https://www.d.shuttle.de/isil/gnupg which is moving along nicely, and psst is the very beginnings of an independent GNU implementation of the ssh protocol IETF draft specification at: https://www.net.lut.ac.uk/psst).

So, Jim, there's plenty of crypto code freely available --- you just have to import it from various countries with greater degrees of "free speech" than our government currently recognizes here in the U.S.

(as is my custom I've removed identifying personal info from your message --- since this is being copied to my editors at LG).

Copyright © 1998, James T. Dennis
Published in The Linux Gazette Issue 35 December 1998

			office	largedisk	links	yamaha	magickeys
			passwd	ftproot	pvtmail	netware	crypto
			relay	project	bootmethod	sysadmin	ipscript
loopfs	mrtg	slimscan	rpm	modutil	libc	dell	remoteroot