Date: Sat, 28 Aug 2004 12:32:56 +0100 From: David Kreil <kreil@ebi.ac.uk> To: Allan Fields <bsd@afields.ca> Cc: David Kreil <kreil@ebi.ac.uk> Subject: Re: "sanitizing" disks: wiping swap, non-allocated space, and file-tails Message-ID: <200408281132.i7SBWuu20662@puffin.ebi.ac.uk> In-Reply-To: Your message of "Sat, 28 Aug 2004 01:16:56 EDT." <20040828051655.GK33859@afields.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear Allan, That's great, thank you so much for the update! Just to guide me - what do you think will be the time scale until you can make your rc scripts and what you've learned in your setup available? If I can afford to wait, this would probably be easiest for me. Else, I'd want to take what you've told me so far, and get struggling on my own. Will I need 5-CURRENT for stuff to work, or can I stick to latest Release? One more question about the rc startup process - is the keyboard initialized before gbde (so that the right keyboard map is used for typing in gbde passwords on non US keyboards)? With many thanks again for your help, David. > > --opJtzjQTFsWo+cga > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Hi, sorry I didn't get back on this sooner.. > > On Sat, Aug 14, 2004 at 05:57:44AM +0100, David Kreil wrote: > >=20 > > > > I wonder, in particular, what issues I have to expect in wanting to k= > eep > > > > system relevant directories like /var on a gdbe partition. > > >=20 > > > The gbde attach should occur early enough during multiuser startup to a= > void > > > such problems, I don't recall if the provided rc script would be suffic= > ient, > > > I'll test a configuration soon, or let me know if you have any luck. > >=20 > > 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,= > =20 > > 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 afte= > r the=20 > > 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;} {pri= > nt}'` > > 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. > >=20 > > 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,= > =20 > > ...), 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 you= > r=20 > > 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. > > > With many thanks again for your help, > >=20 > > David. > >=20 > > ------------------------------------------------------------------------ > > Dr David Philip Kreil ("`-''-/").___..--''"`-._ > > Research Fellow `6_ 6 ) `-. ( ).`-.__.`) > > University of Cambridge (_Y_.)' ._ ) `._ `. ``-..-' > > ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' > > www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' > >=20 > > --=20 > Allan Fields, AFRSL - http://afields.ca > 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 > > --opJtzjQTFsWo+cga > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (FreeBSD) > > iD8DBQFBMBVH90UNcjm0VUERAoCSAKCdTQYHmX6lpxkW7brncYumI+RoXwCbBkJE > na+ibEa/3P0L1+rwVaEBjyQ= > =Xcqz > -----END PGP SIGNATURE----- > > --opJtzjQTFsWo+cga-- > ------------------------------------------------------------------------ Dr David Philip Kreil ("`-''-/").___..--''"`-._ Research Fellow `6_ 6 ) `-. ( ).`-.__.`) University of Cambridge (_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-'
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408281132.i7SBWuu20662>