Kernel Source Divergence, Security (was: booting gbde-encrypted filesystem)

[Allan Fields]

On Fri, Jul 29, 2005 at 01:52:40PM +0200, Poul-Henning Kamp wrote:
> In message <20050729134548.1cc28dr8gg0k4k0g at netchild.homeip.net>, Alexander Leidinger writes:
> >Pawel Jakub Dawidek <pjd at freebsd.org> wrote:
> >
> >> This is not not possible with current GBDE.
> >> I've patches which allows this here:
> >>
> >> 	http://people.freebsd.org/~pjd/patches/gbde.patch
> >
> >I fail to see how this allows an encryted root-FS, it doesn't add gbde
> >support to boot0(ext) or to the loader. It needs access to an unencrypted
> >kernel. I don't think this is what Ronnel had in mind (overlooking the fact
> >that his suggestion to save the passphrase in the loader is insecure).
> 
> There is a difference between loading the kernel from an encrypted volume
> (very hard!) and mounting the root filesystem from an encrypted volume
> (possible with pawels patch.
> 
> Now of course, if your kernel has been trojaned, you're in trouble, but
> then again, most people just worry about their data if the machine gets
> stolen.

Yes, this is all very nice, but when is someone actually going to
commit it? ;)

I don't think it wise to have GBDE and GEOM subsystems which are rather
central to the system require too much fussing around with patches, this
makes the admin's job harder and makes us developers look lazy (though
I know it not to be the case for GEOM folks).

Can we decide on something and get it in the main kernel source
tree?

Further forking the BSD kernel: (sarcasm implied)
    Either that or can we fork GBDE (and other subsystems) into
    three (up to inf.) different concurrent implementations and
    maintain kernel build "knobs" to customize which version is
    compiled?

I'll admit I haven't submitted some of the hacks to GBDE I'd like
to see integrated into the tree, mostly to avoid these types of
issues, where I'd like to see certain features completely implemented
before I post patches.  And then I have the concern: if I post patches,
will they ever get committed?  Should I just wait for an official
implementation by core GEOM developers -- but even pjd isn't committing
some work, why not?

I don't like to get bogged down patching source manually, unless I
have to and I've even explored using a shell script to maintain
FreeBSD kernel source trees, which I still haven't posted on list.

But, who has time to polish a shell script up when you have $N
tasks? -- My latest life-wide TODO list (including some history and
various notes):
   3977   22204  148955		20050517

Further FYI: It's called srctag and is my attempt at automating/unifying kernel
source tree management.  Again I'll reference BSDCan 2004 slides,
but this is rather vain absent my posting the script. ;)
The idea would be to reinforce/automate checkout/build process from
potentially heterogenous source code collections (cvs,cvsup,perforce,rsync,
nfs, patches, etc.) and maintain a properly labelled/date-time
stamped directory which merges the collected source, patches, etc.
ready for build/install.)  Potentially local modifications could
be captured avoiding cvs clumbsiness.  At one point I thought of
using union mounts to combine trees/capture changes, but can this
just as easily be done using standard diff/patch mechanisms?


Some of my gbde work is obviously still not finished, due to time
constraints.  Though I don't intend to wait all-the-way for the
gbde "mega-patch" if I get around to finishing.

( I thought of holding off until I do something important enough
  which really can't be rejected on specific small merits alone.. ;)
  Though, I don't think this is the Open Source commit early/often
  collaborative model.  I'd rather not ram my code design choices
  into a big ball of code, even if I think I'm doing the "right thing"
  so I'll post on-list in hopes of getting feedback like I emailed
  phk about gbde root implementation ideas.  Still taste seems best. )

Another thing on my TODO list as discussed with mdod at BSDCan is
possibility of PAMifying gbde(8) and generally looking at kernel
side key store/management issues.  The idea of hardware integration
/ support was discussed and it might be beneficial to find out some
way to use generic hardware in configuration as an affordable HSM
w/ some degree of key protection.


I've also now been tracking the ongoing work on Linux side with
interest to adoption.  Both device level and vnode level solutions
are valid and of interest.  There was a presentation on TCG (IBM
Trusted Computing hardware) including coverage of TPM, etc.  On the
vnode level there is work toward an integrated solution (eCryptFS)
on the Linux side, I might have an interest in porting this to
FreeBSD and vice-versa for all applicable technologies.


One thing is clear, if I plan on proactively deploying GBDE in a
production environment or promoting it's use, I'd like some assurance
I'll be able to count on coordinated development with timely response
to security or other patches.

The current state of gbde bugs/PRs is something I'd like to help
get resolved if I select gbde for wider adoption.  People trying and
failing to use GBDE is of concern to me being interested in wider
disk encryption use.  In the past I've tried to help on list, but
I think time constraints would prevent me from doing much specific
support work unpaid.


Also, I have a number of "legacy" volumes, personally which use my
patch for password input which is different than pjd's solution so
I have to build a different gbde(8) binary each time I rebuild world
on that machine.


I've noted that perforce might further the divide.  I recognize
it's meant as an experimental code base and it's great if people
make something work in their kernel tree, but if it takes too long
to merge back into CVS (especially when it is requested/working
feature) then that can be prohibitive.  I don't fully grok perforce
yet, it's time consuming learning all these systems.

What ever happened to plain old CVS? (lacking as it can be construed..)
Can't developers settle on one source management tool (per project
at least)?

I attended a presentation at Desktop Developers' Con. 2005 here in
Ottawa where this issue was discussed wrt Open Source desktop
developers.

IMO, this issue of source management lacking central coordination
can only hobble the best intentions of Open Source authors.  How
many systems do we have now?  10,11,12 and you (source maintainers)
expect me to install and use _all_ of these in addition to keeping
track of regular patches if I want to contribute or use most recent
source tree from the projects?


(Note this is not a FreeBSD specific problem and FreeBSD isn't
_that_ bad off.)  I note that KDE is now on svn and Linux is moving
off bk to mercurial (or is it git)?  I heard supposedly bk stopped
working for people due to some commercial decisions made?

So, on the one hand I advocate better source management tools;
but as a user, I note these source management issues are general
impediments to my progress and could also slow down developers/stifle
contribution.


> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

-- 
Allan Fields (afields)                  - Ottawa, Canada (45"10'N 75"56'W)
 Himeji Systems                         http://himejisystems.com
 Afields Research/AFRSL                 http://afields.ca

 2D4F 6806 D307 0889 6125  C31D F745 0D72 39B4 5541