Good evening (here in Spain) to all of you.
I want to sincerely thank you all for the great feedback received on this
topic. I would never have expected to receive some 20 answers in such a short
time! Let me take my time to write your names, because you deserve it:
Thank you Dariush, Adam, Marcel, Lars, Thomas, Peter, Harry, Koba, Ross,
Adrian, and all the others who read the mail.
We've seen lots of interesting points, some of which I'll comment now:
- REMOTE PASSWORD SERVER. It avoids me from having to hardcode the cipher key
somewhere in the filesystem, but presents two handicaps: What if they lose
connection to the Net? and What if they put the HD in another machine, remove
the root password, and put it back in the original machine? By doing this,
the system would boot normally, would get the cipher key and mount the
protected contents, and later they could login as root and access those
contents.
- CIPHER KEY BASED ON THE HARDWARE. They can still remove the root password
and boot the drive again with its original hardware. Moreover it has the
disadvantage of having to recalculate the password and recipher the container
if any hardware component changes. I still have to study Marcel's point about
Palladium.
- MANUALLY ENTER THE PASSWORD LOGGING REMOTELY WHEN SYSTEM BOOTS UP. This one
introduces the sixth sense of the sysadmin (i.e., me) who could take a look
around before entering the pass (check that /etc/passwd is untouched, noone
is logged in...). Even in that case the machine could have been trojanized,
although we could check that point with software packages such as Tiger or
Samhain (eh Javier!! ;D ) making it more difficult for a potential intruder
to neutralize all of our monitoring tools.
- TEMPORARILY MOUNT, LET PROGRAMS READ FILES INTO MEMORY, THEN UNMOUNT.
Unfortunately this one isn't possible, as the protected data won't be config
files for services, but rather .html and .php pages which need to be accessed
very often. It was a good point, I must say.
Other interesting things to look at:
- LICENSING ISSUES. As Peter Cordes commented, the kernel is GPL so if we
integrate code into it, we cannot provide a binary-only version, we should
also give away the sources (or use modules, but we want a monolythic kernel
for obvious security reasons). However I don't see the problem in thinking of
something like this, implementing it, documenting, giving away to the
community... and later configuring it for our particular needs, so that a
client cannot (initially, at least) break it.
I have to leave right now, and I'm taking a copy of this mail to discuss it
with my colleagues. Will continue writing on the topic later or tomorrow,
probably.
Again, thanks to all for your great pieces of advice
Yours
The Pope - Luis Gomez
--
Luis Gomez Miralles
InfoEmergencias - Technical Department
Phone (+34) 654 24 01 34
Fax (+34) 963 49 31 80
[EMAIL PROTECTED]
PGP Public Key available at http://www.infoemergencias.com/lgomez.asc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
