Re: Keeping files away from users - THANKS!!
From: Luis Gomez - InfoEmergencias <[EMAIL PROTECTED]> 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 ; 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 ; Thu, 5 Jun 2003 20:58:39 +0200 (CEST) X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP Old-Return-Path: <[EMAIL PROTECTED]> Organization: InfoEmergencias User-Agent: KMail/1.5.2 References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> 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: <[EMAIL PROTECTED]> Resent-From: debian-security@lists.debian.org X-Mailing-List: archive/latest/12214 X-Loop: debian-security@lists.debian.org List-Post: <mailto:debian-security@lists.debian.org> List-Help: <mailto:[EMAIL PROTECTED]> List-Subscribe: <mailto:[EMAIL PROTECTED]> List-Unsubscribe: <mailto:[EMAIL PROTECTED]> Precedence: list Resent-Sender: [EMAIL PROTECTED] Resent-Date: Thu, 5 Jun 2003 14:15:46 -0500 (CDT) Return-Path: [EMAIL PROTECTED] 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. You could just make md5 checksums of the whole system and store the checksums on another machine/floppy disk or something of that nature. Then when you would like to remount the filesystem you could always verify the checksums to see if you are trojaned or not. - 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
Re: Keeping files away from users - THANKS!!
From: Luis Gomez - InfoEmergencias <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>; 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 <[EMAIL PROTECTED]>; Thu, 5 Jun 2003 20:58:39 +0200 (CEST) X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP Old-Return-Path: <[EMAIL PROTECTED]> Organization: InfoEmergencias User-Agent: KMail/1.5.2 References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> 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: <[EMAIL PROTECTED]> Resent-From: [EMAIL PROTECTED] X-Mailing-List: <[EMAIL PROTECTED]> archive/latest/12214 X-Loop: [EMAIL PROTECTED] List-Post: <mailto:[EMAIL PROTECTED]> List-Help: <mailto:[EMAIL PROTECTED]> List-Subscribe: <mailto:[EMAIL PROTECTED]> List-Unsubscribe: <mailto:[EMAIL PROTECTED]> Precedence: list Resent-Sender: [EMAIL PROTECTED] Resent-Date: Thu, 5 Jun 2003 14:15:46 -0500 (CDT) Return-Path: [EMAIL PROTECTED] 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. You could just make md5 checksums of the whole system and store the checksums on another machine/floppy disk or something of that nature. Then when you would like to remount the filesystem you could always verify the checksums to see if you are trojaned or not. - 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 discu
Re: Keeping files away from users - THANKS!!
On Thu, Jun 05, 2003 at 08:58:43PM +0200, Luis Gomez - InfoEmergencias wrote: > 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 suppose if you used a BSD system, you could do this kernel modification and not have to provide the source. The userland side of the system is going to be very similar. Geoff Crompton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users - THANKS!!
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]
Re: Keeping files away from users - THANKS!!
On Thu, Jun 05, 2003 at 08:58:43PM +0200, Luis Gomez - InfoEmergencias wrote: > 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 suppose if you used a BSD system, you could do this kernel modification and not have to provide the source. The userland side of the system is going to be very similar. Geoff Crompton
Re: Keeping files away from users - THANKS!!
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
