[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux-NG - security

Dunno anything about TCPA, sorry.

On 2002.12.30 09:24 Russell Coker wrote:
> This would be a bit like turning Linux into a
> sort of MVS
> and then beyond a few strides, whilst still being Linux, and it
> only work on
> systems that are a lot like toned-down mainframes.  Still, Linux'
> strongest strength
> is its modular versatility.

I wasn't aware of any crypto support in mainframes.  Do you have any
references as to what the S/390 family supports in this regard?

I was meaning in terms of channels bypassing processors. Mainframe channels don't neccesarily need to use a processor, or even classical memory sometimes, they can do software<>channel<>device.

> system.  This system could also define secure pre-boot
> so that system
> recovery methods that may otherwise form a security flaw in the
> may be
> configured to only allow authenticated users of the system (who do
> necessarily
> have super-user access) to boot using these methods -- allowing
> compromise
> with distributing root passwords and so-forth.  Of course, the
> filesystem security
> methods would have to be updated a little, but what's that compared
> all this?

Doing this requires one of two things:

1)  Encryption hardware in the CPU module such as TCPA, which is not
available to general Linux users (we can only guess at what some of
the .mil
people might really be doing with Linux).

2)  Boot loader on an external device that can be secured.  The
simplest way
of doing this is having a kernel and initrd with cryptoapi support and
encryption password on a floppy disk.  You boot from the disk and then
it in a safe.  For a laptop you could leave the boot floppy home when
travelling (so that if someone steals your laptop and reboots it then
can't get access to the data - NB this requires that you not use the
"Hibernation" facility).

Option 2 is on my to-do list.  However last time I tried crypto-api
didn't compile with 2.4.20...

Perhaps I didn't make myself clear. I'll explain more graphically (sorry to those using non-monospaced fonts)

You have a bootloader, a pre-vm that defines a minimal threading set, a linux security vm (low priority) a linux kernel vm, a security interface to comminucate with the authentication system. These are all in software; like so (same level of operation on same line):

|               Bootloader                | [Pre-boot level]
|                 Pre-VM                  | [Hardware access level]
| Security VM  |  Linux Kern / Kernel VM  | [Kernel Level]
| Security Iface   =|= Auth Sys <|>  OS   | [Userspace level]

To explain in more text detail:

After Booting, the bootloader loads the Pre VM. This can be considered like the Linux Virtual Machine which interfaces between the Linux kernel and hardware, turning Linux system calls into the correct I/O mechanisms. This Pre VM, however, is minimally multithreading, unlike the existing Linux VM (sort of). It spawns two virtual processes, first the security VM, which sleeps until the interface makes a call to it, and after checking authentication using that VM (which, due to the Pre-VM, also has access to hardware), spawns the Linux Kernel (or possibly its current VM with a hardware system defined interfacing with the Pre-VM) - the Security VM has its own "filesystem" that is, in effect, a one-way password hash. The Security VM spawns a userspace-level Interface (but acts like a kernel) that can do cryptographic functions, and the Linux kernel boots the OS. Once the OS has booted and the Authentication System starts, it switches its memory interface to be the security interface, while the input remains in the linux kernel (This could be difficult to achieve without writing some new calls to do kernel switching). So far we have two operating systems that don't have anything to do with each other's memory space running side-by-side, sharing a direct pipe between the Authen System in the Operating System, and the Security interface. The operating system and kernel interact on an I/O level with the Authentication system that will do all authentication verification and simply return a true/false uid changing authorization to the operating system.

This is, of course, all hypothetical, and is nearly as far-fetched as the original proposition, and also good luck reading my extended brainsplatter.

Francis Whittle

Reply to: