"sanitizing" disks: wiping swap, non-allocated space, and file-tails

[David Kreil]

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),'  ((!.-'