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

[Allan Fields]

Hi, sorry I didn't get back on this sooner..

On Sat, Aug 14, 2004 at 05:57:44AM +0100, David Kreil wrote:
> 
> > > 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 
> "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=4
	random_flush=yes
    _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.

> With many thanks again for your help,
> 
> David.
> 
> ------------------------------------------------------------------------
> 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),'  ((!.-'
> 

-- 
 Allan Fields, AFRSL - http://afields.ca
 2D4F 6806 D307 0889 6125  C31D F745 0D72 39B4 5541
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20040828/be3a6b84/attachment.bin