From owner-freebsd-fs@FreeBSD.ORG Thu Jul 14 20:37:45 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C1E616A430 for ; Thu, 14 Jul 2005 20:37:45 +0000 (GMT) (envelope-from kreil@ebi.ac.uk) Received: from maui.ebi.ac.uk (maui.ebi.ac.uk [193.62.196.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 743ED43D45 for ; Thu, 14 Jul 2005 20:37:44 +0000 (GMT) (envelope-from kreil@ebi.ac.uk) Received: from parrot.ebi.ac.uk (parrot.ebi.ac.uk [193.62.196.69]) by maui.ebi.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id j6EKbgQ05773; Thu, 14 Jul 2005 21:37:42 +0100 (BST) Received: from parrot.ebi.ac.uk (kreil@localhost) by parrot.ebi.ac.uk (8.11.6/8.11.6) with ESMTP id j6EKbft12951; Thu, 14 Jul 2005 21:37:42 +0100 Message-Id: <200507142037.j6EKbft12951@parrot.ebi.ac.uk> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Allan Fields In-Reply-To: Your message of "Sat, 28 Aug 2004 01:16:56 EDT." <20040828051655.GK33859@afields.ca> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Jul 2005 21:37:41 +0100 From: David Kreil X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=-8, required 5, HABEAS_SWE -8.00) Cc: freebsd-fs@freebsd.org, David Kreil Subject: Re: preventing information leakage in gbde protected system X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2005 20:37:45 -0000 Dear Allan, After a job induced pause in my strong interest in encryption solutions, I'm now slowly returning to the case. You have kindly provided good advice when we were in touch last year and I was wondering whether you had any further information regarding setting up a system to be gbde protected early enough during system boot to avoid leakage of sensitive information in /var, /etc, and possible the root (/). With many thanks and best regards, David. > > > > > I wonder, in particular, what issues I have to expect in wanting to keep > > > > system relevant directories like /var on a gdbe partition. > > > > > > The gbde attach should occur early enough during multiuser startup to avoid > > > such problems, I don't recall if the provided rc script would be sufficient, > > > I'll test a configuration soon, or let me know if you have any luck. > > > > Have you yet had a chance to give it a try? > > > > I noticed that there have been additions to the rc.d script, like=20 > > "gbde_swap_enable". Would you know whether, if I used the rc.d approach,= > > > Yes, it provides a good way to quickly enable encrypted swap. > > > whether that will that be early enough that I can have /var encrypted? > > Else, how/where should I otherwise link in (as early as possible but after the > > non-US keyboard support has loaded)? > > Key roles /var will play during startup: > - logging: usually syslog or others want to write to /var/log > - entropy: the entropy database default resides in /var/db (which > is interesting, what effect does encrypting this have?) > - run files: some daemons will create pid and lock files, others > create sockets > - networking: some network daemons use /var/db > - mail: sendmail or other MDA might try to deliver some emails > - savecore: crash dumps would be handled > - etc.. > > Therefore you are correct, doing it properly requires that /var be > mounted well before any daemons start. Following rcorder we get a > ranking w/ a few possible entry points: > preseedrandom > rcconf.sh > initrandom > dumpon > vinum > gbde_swap <- > gbde <- here (works fine, no dependencies on /var yet) > ccd // should ccd come before gbde ? > swap1 > early.sh -> /etc/rc.early <- or perhaps here for custom attaches > fsck > root > mountcritlocal > var > cleanvar [ /var ] > addswap > sysctl > random [ /var/db/entropy ] > NETWORKING [ /var/db .. ] > mountcritremote > syslogd [ /var/log ] > savecore [ /var/crash ] // If encrypted swap, may not work > etc. > > # grep -nR var `rcorder /etc/rc.d/*|awk '/mountcritlocal/{nextfile;} {print}'` > > Note with the provided gbde rc script: -l/-L is required and expects > lock files to be made in /etc though you can also specify a gbde_lockdir > in /etc/rc.conf such as /etc/bde to store all your keys. (Remember > to take frequent back-ups). > > > > There are several approaches to securing /etc, but I can elaborate > > > more after further testing. The short term approach is not storing > > > private keys, etc. on an unencrypted root. Support for encrypted > > > root is possible w/ some work, but there are a few issues to sort > > > out first. > > > > Do I need an encrypted root? What would be the main benefit of this? > > The benefit would be to guarantee that nothing of importance is > stored in the clear on /. > > Normally / is limited to system files, but as you've mentioned system > files can be private keys or password databases, and it's possible for > something else to be written by anyone w/ sufficient permissions. > Restrictive permissions combined with encryption of sensitive areas > of the file system could prevent most leakage scenarios absent full > disk or root encryption. > > > I think I'd need an encrypted /var (as it holds logs, mail&printer spool, > > ...), and possibly /etc/ssh/ - any other sensitive system areas (besides > > swap). > > You could easily use gbde here by using a vnode backed md, though > there are some more direct approaches to vnode level encryption: > > Example md usage > setup: > mv /etc/ssh /etc/ssh.dist > mdconfig -a -t vnode -f /etc/ssh.bde -s 4m -u 22 > gbde init /dev/md22 -f /dev/stdin<<-_INIT_ > number_of_keys=3D4 > random_flush=3Dyes > _INIT_ > gbde attach /dev/md22 > newfs -o space /dev/md22.bde > mkdir -p /etc/ssh; chmod 755 /etc/ssh > mount /dev/md22.bde /etc/ssh > cp -RPp /etc/ssh.dist/* /etc/ssh &&\ > rm -rf /etc/ssh.dist > startup: > gbde attach /dev/md22 &&\ > mount /dev/md22.bde /etc/ssh > shutdown: > umount /dev/md22.bde &&\ > gbde detach /dev/md22 > > The same of course would apply to any private keys/password databases > and certificates. > > > Where do you stand now with your setup? I'd be grateful to learn from your > > experience. > > I've done the encrypted /var and /tmp successfully and w/ provided rc > scripts as well. I will continue experimentation on GBDE for > root/full system image setups. > > I plan to elaborate further on the subject and will post more details > to the lists. I can try to collect some practical examples, as I > originally set out to do earlier this summer, and put up a web page. > --------------------------------------------------------------------------- Dr David Philip Kreil Research Fellow, Darwin College, | WWTF Vienna Science Chair of University of Cambridge | Bioinformatics, Dept of Biotechnology, ++44 1223 764107, fax 7092 810040 | c/o IAM / BOKU, A-1190 Muthgasse 18 www.inference.phy.cam.ac.uk/dpk20 | ++43 1 360066830