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
would
> 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
authentication
> so that system
> recovery methods that may otherwise form a security flaw in the
system
> may be
> configured to only allow authenticated users of the system (who do
not
> necessarily
> have super-user access) to boot using these methods -- allowing
minimal
> 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
to
> all this?
Doing this requires one of two things:
1) Encryption hardware in the CPU module such as TCPA, which is not
currently
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
the
encryption password on a floppy disk. You boot from the disk and then
lock
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
they
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
still
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]
+--------------------v--------------------+
| Pre-VM | [Hardware access level]
+------^v------+-----------^v-------------+
| Security VM | Linux Kern / Kernel VM | [Kernel Level]
+-------^v-----+----+-----^v-----+---^v---+
| 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
(fudje)
Reply to: