[KLUG Advocacy] Re: linux security

Adam Tauno Williams awilliam at whitemice.org
Sat Feb 12 15:35:37 EST 2005


> >Nah, they just changed the Administrator account password, and then put
> >the old value back.  You'd never know.  The format of the SAM is known,
> >boot up without that pesky OS in the way and it is all just blocks on a
> >platter - move them around at will.
> Windows 2000 and above has an Encrypted File System option that is 
> supposed to protect you from this.  The actual data on the drive is 
> encrypted, so you can't read it without the key which is (I think) 
> supposed to be stored on a physically secured server.  

Yes, but again - useless for disconnected users (laptops) for which
physical security is obviously not an option.  

A laptop locked in a cabinet behind two locked doors and a surveillance
system isn't much use. :)

> If memory serves, 
> this server is not connected to the network, and the only way to recover 
> an encryption key if it gets lost is with a floppy that you lock in the 
> safe unless it's being used.  

All rather impractical, to the point of being silly.

> I studied it a while back, though, and I 
> think I concluded that the data is too easy to recover in the case of 
> screwup, therefore not very secure.

You can do this in Linux,  mount a filesystem via loopback and apply
encryption but (a) if the key isn't secure the data isn't (b) the
performance penalty might really hurt and (c) you'd better really trust
that that crypter never screws up data.

> >*NO* operating system can make a device that can be physically accessed
> >secure.  You need something built-in way down in the metal if you want
> >both security AND physical access: a large crypt key on a USB stick that
> >the disk controller uses to encrypt/decrypt block I/O operations to a
> >disk - and then when you go away you take the USB stick with you - thus
> >'breaking' the system so it cannot work.
> This is an inherent problem, like you said.  Encryption and security are 
> handled buy the operating system, and if you have physical access to the 
> machine, especially the system hard drive, you can read it without the 
> operating system.  

Right, UNLESS encryption is in the hard drive's firmware.  In that case
you'd need to remove the platters, insert them into a drive with
alternate firmware (this probably requires a clean room, and at least a
very steady hand), read the blocks and decrypt.  All that makes for a
serious deterrent - if someone is willing to go through that effort and
expense you're going to get nailed one way or the other.

> The Windows SAM format is probably not published, 

The Windows SAM a registry hive in NT/2000 and in a hatcheted version of
SQL-Server in 2000/XP/2003 (the hind end of the LDAP/KDC/RPC mess that
is ADS).

> but nothing is all that hard to reverse engineer, and it's been done. 
> Eggheads at places like Intel and Microsoft are working on some scary 
> techniques (Palladium, Trusted Computing Initiative, etc) that will 
> implement security at the hardware level.  This is the next step, if 
> they can manage to do it right and not just make it impossible for you 
> to play your mp3 collection without checking with Big Brother.  

I think this can be done (and will be done) in a user-friendly (even
hacker-friendly) manner.  Will some troop of capitalist running dogs try
to use it to further one of their many nefarious agendas?  Without a
doubt;  but that doesn't mean the technology is 'evil'.  The technology
answers a legitimate need.

> >Applications can of course encrypt their data, which may or may not be
> >secure depending upon how they do it.  But an OS needs to be able to
> >boot so they can't be secure without making it a pain for the user - for
> >instance you can set a secret on a KDC's principal store - but you need
> >to enter/load that secret everytime you restart the KDC (reboot the
> >computer), but this is rarely done since it is a REAL PITA.
> The inherent problem:  the more secure a system is, the less convenient 
> it is.  

True, now.  But fundamentaly false.  This is because security is still a
bolted-on thing, and exists too high in the stack, and every app/service
is running off to implement their own counter measures.

Take Kerberos V;  a kerbized network is MUCH more secure than a
non-kerbized network - AND much easier for the end user to use.  This is
because their is ONE security model and all the application/services
just have to get on the wagon.  The vulnerability of the network is
largely pushed to the KDC(s) and focus can be heaped on making those few
host bullet proof. (But again this does nothing for disconnected users).

> It's not a completely linear relationship, but you can't make 
> something more secure without increasing the possibility that you'll end 
> up locking yourself out.

On a network you always have a back door - the KDC's/DSA's system
console.  slapcat + vi ! :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.kalamazoolinux.org/pipermail/advocacy/attachments/20050212/f6fb5c4a/attachment.bin


More information about the Advocacy mailing list