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

From: Allan Fields (bsd_at_afields.ca)
Date: 07/31/05

  • Next message: Poul-Henning Kamp: "Re: Kernel Source Divergence, Security (was: booting gbde-encrypted filesystem)" 
    Date: Sun, 31 Jul 2005 09:59:19 -0400
To: Poul-Henning Kamp <phk@haven.freebsd.dk>

    On Fri, Jul 29, 2005 at 01:52:40PM +0200, Poul-Henning Kamp wrote:
    > In message <20050729134548.1cc28dr8gg0k4k0g@netchild.homeip.net>, Alexander Leidinger writes:
    > >Pawel Jakub Dawidek <pjd@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@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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Poul-Henning Kamp: "Re: Kernel Source Divergence, Security (was: booting gbde-encrypted filesystem)"

    Relevant Pages

    • Re: [PATCH] delete devfs
      ... been merging patches at a rate of about 10MB/month. ... Andrew would like to see a 2.6 tree which continues to change ... In his vision of the future, the kernel.org kernel will be the most ... keeps the developers happy and gets new code out to users quicker. ...
      (Linux-Kernel)
    • Re: RFD: Kernel release numbering
      ... A different approach would be to not release a 'stable' kernel at all, ... applying patches that might be relevant to them. ... So I have been sending all my patches to Andrew to go in the -mm tree, ... But more recently I have discovered that quite a few key developers ...
      (Linux-Kernel)
    • research questionnaire about kernel development
      ... This is a request for comments on 14 assertions about kernel ... kernel development occurs and how developers respond to bug reports. ... Assertion 2: Files with lots of patches remain ...
      (Linux-Kernel)
    • [PATCH, RFC] A development process document
      ... This is an extended document intended to help interested developers, ... and their employers work with the kernel development process. ...
      (Linux-Kernel)
    • [PATCH] A development process document, V2
      ... Add a document describing the kernel development process. ... +With the growth of Linux has come an increase in the number of developers ...
      (Linux-Kernel)