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

Re: Linux-NG - security



On Sun, 29 Dec 2002 22:48, Francis Whittle wrote:
> > Eventually, it'd be nice if the kernel interacted with hardware (being
> > paranoid all the time!) so that user credentials never get stored in
> > memory, nor reside anywhere directly (except in the piece of
> > hardware),
> > nor get transmitted anywhere, so that even the kernel has zero
> > knowledge
> > of the user's creds.  But that requires hardware firms to work with
> > us,
> > so that may be a ways off.
>
> This is a nice idea indeed, but for the truly paranoid you'd need to be
> able
> to guarantee that the hardware was not accessible.  This would also, in
> effect,

TCPA does some of this, but we won't get Linux certified as a TCPA OS.  If we 
could hack the TCPA signature code somehow, maybe the next task for 
distributed.net...

> require kernel hooks to be extended waaaay into user-space, such that an
> authentication system could simply tell the kernel (perhaps using a
> module of some
> description) to open a device for a direct pipe, straight through the
> processor no
> memory channels required, and _that_ would require an amount of
> processor and
> channel re-engineering.

I thought that was part of TCPA.  The encryption gets done in hardware in the 
CPU module and you can communicate with it securely.  However an application 
running on the local machine can always be molested by the kernel.  If you 
can't trust the kernel then the application is not safe.

> 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?

> 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...


For anyone who's interested in security, I think it's best to concentrate your 
efforts on projects such as GR-Sec, OpenWall, SE Linux, and Crypto-API.  
These are projects that are achieving real things right now, but which could 
do with some additional work to get things working better.  Once we get all 
those working really well then we can look at other things to improve.

I can offer a list of things to work on for anyone who's interested.  Also 
anyone who wants to help out in SE Linux will be very welcome.  There's more 
work in the Debian side of things than Brian and I can handle at the moment.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



Reply to: