preventing information leakage in gbde protected system

[David Kreil]

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