From: Luis Gomez - InfoEmergencias <lgomez@infoemergencias.com>
To: debian-security@lists.debian.org
Subject: Re: Keeping files away from users - THANKS!!
Date: Thu, 5 Jun 2003 20:58:43 +0200
MIME-Version: 1.0
Received: from murphy.debian.org ([146.82.138.6]) by
mc5-f31.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 5 Jun
2003 12:37:03 -0700
Received: from localhost (localhost [127.0.0.1])by murphy.debian.org
(Postfix) with QMQPid 592B11F68B; Thu, 5 Jun 2003 14:15:46 -0500 (CDT)
Received: from marianela.infoemergencias.com
(221.Red-213-96-93.pooles.rima-tde.net [213.96.93.221])by murphy.debian.org
(Postfix) with ESMTP id EB5001FB7Afor <debian-security@lists.debian.org>;
Thu, 5 Jun 2003 13:56:39 -0500 (CDT)
Received: from adelita.infoemergencias.com (unknown [192.168.1.7])by
marianela.infoemergencias.com (Postfix) with ESMTP id 840801323for
<debian-security@lists.debian.org>; Thu, 5 Jun 2003 20:58:39 +0200 (CEST)
X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP
Old-Return-Path: <lgomez@infoemergencias.com>
Organization: InfoEmergencias
User-Agent: KMail/1.5.2
References: <[🔎] 200306050930.51198.lgomez@infoemergencias.com>
<oprqawaja8cyxqgb@mail.grupocom.com.ar>
In-Reply-To: <oprqawaja8cyxqgb@mail.grupocom.com.ar>
Message-Id: <[🔎] 200306052058.43083.lgomez@infoemergencias.com>
X-Spam-Status: No, hits=-17.7
required=4.0tests=BAYES_20,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE,
USER_AGENT_KMAILautolearn=ham version=2.53-lists.debian.org_2003_04_28
X-Spam-Level: X-Spam-Checker-Version: SpamAssassin
2.53-lists.debian.org_2003_04_28 (1.174.2.15-2003-03-30-exp)
Resent-Message-ID: <wbjDxB.A.sgF.ib53-@murphy>
Resent-From: debian-security@lists.debian.org
X-Mailing-List: <debian-security@lists.debian.org> archive/latest/12214
X-Loop: debian-security@lists.debian.org
List-Post: <mailto:debian-security@lists.debian.org>
List-Help: <mailto:debian-security-request@lists.debian.org?subject=help>
List-Subscribe:
<mailto:debian-security-request@lists.debian.org?subject=subscribe>
List-Unsubscribe:
<mailto:debian-security-request@lists.debian.org?subject=unsubscribe>
Precedence: list
Resent-Sender: debian-security-request@lists.debian.org
Resent-Date: Thu, 5 Jun 2003 14:15:46 -0500 (CDT)
Return-Path: bounce-debian-security=steve11523=hotmail.com@lists.debian.org
X-OriginalArrivalTime: 05 Jun 2003 19:37:03.0897 (UTC)
FILETIME=[D751F890:01C32B99]
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
lgomez@infoemergencias.com
PGP Public Key available at http://www.infoemergencias.com/lgomez.asc
--
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org