Technical discussion regarding security issues in NetBSD

Thor Lancelot Simon | 23 Mar 2009 03:33

Re: summer of code - scrub feature

On Mon, Mar 23, 2009 at 02:26:40AM +0000, Alistair Crooks wrote:
> 
> If you're going down this route, you should also be encrypting any
> swap partitions, of course, using tempested hardware, and wearing tin
> foil on your head.  As ever, this is a question of what's possible,
> and of securing yourself as much as is economically and comfortably
> possible.

That's just silly -- and it goes nowhere to address my basic point,
which is that causing extra disk writes -- much less the painstakingly
flushed multiple overwrites that, for example, rm -P does -- today, is
much, much more expensive than just encrypting the entire volume and
being done with it.

I think it's a bad idea to waste effort on zeroizing erased data when
the same effort could be spent making it easier to do the _cheaper_ 
operation of just encrypting the data in the first place.  Jibes about
tinfoil hats are unhelpful, but make them if you like; I am done wasting
my time being spat on for talking common sense to the sky while it's
raining.

Thor

David Holland | 24 Mar 2009 12:21

Picon

Re: summer of code - scrub feature

On Sun, Mar 22, 2009 at 10:33:37PM -0400, Thor Lancelot Simon wrote:
 > [...] and it goes nowhere to address my basic point,
 > which is that causing extra disk writes -- much less the painstakingly
 > flushed multiple overwrites that, for example, rm -P does -- today, is
 > much, much more expensive than just encrypting the entire volume and
 > being done with it.

Sure, except encrypting the volume isn't equivalent. Cryptosystems
have limited lifetimes. The bits on a discarded drive platter are,
potentially, exposed indefinitely. For people who care about this
stuff, making an adversary wait a dozen so years before a brute-force
attack becomes feasible might or might not be an acceptable tradeoff.

--

-- 
David A. Holland
dholland <at> netbsd.org

Thor Lancelot Simon | 24 Mar 2009 13:04

Re: summer of code - scrub feature

On Tue, Mar 24, 2009 at 11:21:34AM +0000, David Holland wrote:
> On Sun, Mar 22, 2009 at 10:33:37PM -0400, Thor Lancelot Simon wrote:
>  > [...] and it goes nowhere to address my basic point,
>  > which is that causing extra disk writes -- much less the painstakingly
>  > flushed multiple overwrites that, for example, rm -P does -- today, is
>  > much, much more expensive than just encrypting the entire volume and
>  > being done with it.
> 
> Sure, except encrypting the volume isn't equivalent. Cryptosystems
> have limited lifetimes. The bits on a discarded drive platter are,
> potentially, exposed indefinitely. For people who care about this
> stuff, making an adversary wait a dozen so years before a brute-force
> attack becomes feasible might or might not be an acceptable tradeoff.

A dozen years for a brute-force attack on AES?  You *are* pessimistic!

--

-- 
Thor Lancelot Simon	                                   tls <at> rek.tjls.com
    "Even experienced UNIX users occasionally enter rm *.* at the UNIX
     prompt only to realize too late that they have removed the wrong
     segment of the directory structure." - Microsoft WSS whitepaper

David Holland | 24 Mar 2009 17:26

Picon

Re: summer of code - scrub feature

On Tue, Mar 24, 2009 at 08:04:47AM -0400, Thor Lancelot Simon wrote:
 > > Sure, except encrypting the volume isn't equivalent. Cryptosystems
 > > have limited lifetimes. The bits on a discarded drive platter are,
 > > potentially, exposed indefinitely. For people who care about this
 > > stuff, making an adversary wait a dozen so years before a brute-force
 > > attack becomes feasible might or might not be an acceptable tradeoff.
 > 
 > A dozen years for a brute-force attack on AES?  You *are* pessimistic!

Yes, well, maybe it gets broken. Or, quantum computers or little green
men appear and make all our current cryptosystems obsolete. Or
whatever. You don't know, that's the point. And if one goes by what
appear to be the typical secrecy habits of governments, the timeframe
can potentially be a lot longer than a dozen years.

Encryption is a fine precaution; it doesn't mean that scrubbing isn't
worthwhile also.

--

-- 
David A. Holland
dholland <at> netbsd.org

Christos Zoulas | 23 Mar 2009 04:06

Re: summer of code - scrub feature

In article <20090323023336.GA26368 <at> panix.com>,
Thor Lancelot Simon  <tls <at> rek.tjls.com> wrote:
>On Mon, Mar 23, 2009 at 02:26:40AM +0000, Alistair Crooks wrote:
>> 
>> If you're going down this route, you should also be encrypting any
>> swap partitions, of course, using tempested hardware, and wearing tin
>> foil on your head.  As ever, this is a question of what's possible,
>> and of securing yourself as much as is economically and comfortably
>> possible.
>
>That's just silly -- and it goes nowhere to address my basic point,
>which is that causing extra disk writes -- much less the painstakingly
>flushed multiple overwrites that, for example, rm -P does -- today, is
>much, much more expensive than just encrypting the entire volume and
>being done with it.
>
>I think it's a bad idea to waste effort on zeroizing erased data when
>the same effort could be spent making it easier to do the _cheaper_ 
>operation of just encrypting the data in the first place.  Jibes about
>tinfoil hats are unhelpful, but make them if you like; I am done wasting
>my time being spat on for talking common sense to the sky while it's
>raining.

I think it is a lot more useful making cgd easy to configure/use during
installation rather than spending a lot of time trying to erase data
and in the end giving the user the false sense of security since we
are not going to be solving the spared sector problem.

christos

(Continue reading)

David Brownlee | 23 Mar 2009 09:42

Picon

Re: summer of code - scrub feature

On Mon, 23 Mar 2009, Christos Zoulas wrote:

> In article <20090323023336.GA26368 <at> panix.com>,
> Thor Lancelot Simon  <tls <at> rek.tjls.com> wrote:
>> On Mon, Mar 23, 2009 at 02:26:40AM +0000, Alistair Crooks wrote:
>>>
>>> If you're going down this route, you should also be encrypting any
>>> swap partitions, of course, using tempested hardware, and wearing tin
>>> foil on your head.  As ever, this is a question of what's possible,
>>> and of securing yourself as much as is economically and comfortably
>>> possible.
>>
>> That's just silly -- and it goes nowhere to address my basic point,
>> which is that causing extra disk writes -- much less the painstakingly
>> flushed multiple overwrites that, for example, rm -P does -- today, is
>> much, much more expensive than just encrypting the entire volume and
>> being done with it.
>>
>> I think it's a bad idea to waste effort on zeroizing erased data when
>> the same effort could be spent making it easier to do the _cheaper_
>> operation of just encrypting the data in the first place.  Jibes about
>> tinfoil hats are unhelpful, but make them if you like; I am done wasting
>> my time being spat on for talking common sense to the sky while it's
>> raining.
>
> I think it is a lot more useful making cgd easy to configure/use during
> installation rather than spending a lot of time trying to erase data
> and in the end giving the user the false sense of security since we
> are not going to be solving the spared sector problem.

(Continue reading)

Todd Vierling | 23 Mar 2009 13:36

Picon

Re: summer of code - scrub feature

On Mon, Mar 23, 2009 at 4:42 AM, David Brownlee <abs <at> netbsd.org> wrote:
>        A SoC project to add cgd support to the bootblocks and code to
>        pass across to the kernel could be very worthwhile...

/me perks up and peers out from his cubicley jail lined with systems
unfortunately not running nbsd....

There's a reason every single one of my Windoze systems use TrueCrypt
system drive level encryption.  Not one sector hits the disk without
going through at least an AES-Twofish cascade.

On Mon, Mar 23, 2009 at 5:06 AM, Geert Hendrickx <ghen <at> telenet.be> wrote:
> ... but it breaks unattended reboots for servers. 

TPM.

If that's too tinfoil-hat to bear, too inflexible in the face of
motherboard failure, or too locked in to x86 (and it is):  a carefully
constructed ramdisk or tiny unencrypted root partition, and a "mount
-o remount /" (or upper layer union mount, or just a very crafty
symlink farm) can allow cgdconfig to be part of an unattended boot
process.  Depending on how it's done, the key can be embedded in the
ramdisk, on a separate USB token/drive, or made to be a combination of
the two....

(Yes, I've done this before; my home server was set up this way since
the early days of cgd's existence.  Pop out the thumbdrive on which
half of the key lived, and the system would not boot.)

/me now returns to working on far less interesting things for a living....

(Continue reading)

David Brownlee | 23 Mar 2009 14:12

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, 23 Mar 2009, Todd Vierling wrote:

> On Mon, Mar 23, 2009 at 4:42 AM, David Brownlee <abs <at> netbsd.org> wrote:
>>        A SoC project to add cgd support to the bootblocks and code to
>>        pass across to the kernel could be very worthwhile...
>
> /me perks up and peers out from his cubicley jail lined with systems
> unfortunately not running nbsd....
>
> There's a reason every single one of my Windoze systems use TrueCrypt
> system drive level encryption.  Not one sector hits the disk without
> going through at least an AES-Twofish cascade.

 	Very reasonable approach - our Windows laptops are all
 	setup similarly. Its very simple to switch a existing
 	Windows box across to truecrypt, and from the user's
 	perspective after that they just have a passphrase to type
 	before they boot.

 	Converting a running system to an encryped filesystem without
 	requiring a dump/restore is a very nice additional feature, but
 	I think NetBSD would really benefit from 'just' the cgd support
 	in the bootblocks and passing the relevant data across to the
 	kernel so it can get a cgd encrypted root filesystem...

 	Now... where could we find someone willing to at least mentor
 	such a project, if not take it on as a student? :)

--

-- 
 		David/absolute       -- www.NetBSD.org: No hype required --

(Continue reading)

Todd Vierling | 23 Mar 2009 14:22

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, Mar 23, 2009 at 9:12 AM, David Brownlee <abs <at> netbsd.org> wrote:
>        Converting a running system to an encryped filesystem without
>        requiring a dump/restore is a very nice additional feature, but
>        I think NetBSD would really benefit from 'just' the cgd support
>        in the bootblocks and passing the relevant data across to the
>        kernel so it can get a cgd encrypted root filesystem...

Works for workstations, if the bootblocks have passphrase entry (and
better yet, cgd decrypt support to load the kernel itself from an
encrypted root); that would work much like other full-disk encryption
systems.

Without something like TPM, doesn't solve the unattended server
problem, though perhaps that does require a more complex solution
(such as a ramdisk or small root partition, over which / is remounted)
to allow the key to be stored in a more flexible manner.

Collectively this sounds more like two projects to me, though the
latter could suffice for both cases, for a first stab at it.  The
latter is also less low-level code and more scripting work (and
perhaps crunchgen for space), which may make multiplatform support
less painful.  Mentors' mileage may vary.

--

-- 
-- Todd Vierling <tv <at> duh.org> <tv <at> pobox.com> <todd <at> vierling.name>

David Brownlee | 23 Mar 2009 17:54

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, 23 Mar 2009, Todd Vierling wrote:

> On Mon, Mar 23, 2009 at 9:12 AM, David Brownlee <abs <at> netbsd.org> wrote:
>>        Converting a running system to an encryped filesystem without
>>        requiring a dump/restore is a very nice additional feature, but
>>        I think NetBSD would really benefit from 'just' the cgd support
>>        in the bootblocks and passing the relevant data across to the
>>        kernel so it can get a cgd encrypted root filesystem...
>
> Works for workstations, if the bootblocks have passphrase entry (and
> better yet, cgd decrypt support to load the kernel itself from an
> encrypted root); that would work much like other full-disk encryption
> systems.

 	I think that would be the ideal case for any mahine which
 	doesn't require unattended reboot - the only unencrypted
 	data on the disk would be the bootblocks and some cdg config
 	(which may well be written into the bootblocks). Once installed
 	it should be transparent to the user including updating kernels
 	and anything other than bootblocks :)

> Without something like TPM, doesn't solve the unattended server
> problem, though perhaps that does require a more complex solution
> (such as a ramdisk or small root partition, over which / is remounted)
> to allow the key to be stored in a more flexible manner.
>
> Collectively this sounds more like two projects to me, though the
> latter could suffice for both cases, for a first stab at it.  The
> latter is also less low-level code and more scripting work (and
> perhaps crunchgen for space), which may make multiplatform support

(Continue reading)

Jan Danielsson | 23 Mar 2009 21:10

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

David Brownlee wrote:
[---]
>> Collectively this sounds more like two projects to me, though the
>> latter could suffice for both cases, for a first stab at it.  The
>> latter is also less low-level code and more scripting work (and
>> perhaps crunchgen for space), which may make multiplatform support
>> less painful.  Mentors' mileage may vary.
> 
>     Could you clarify how the latter would work - is the intention
>     to allow the system to boot up to a point where the administrator
>     can connect in to finish cgd configuration and remount?
> 
>     I can see the utility of both, and would be very happy with
>     either :)

    I've previously been using the sysctl init.chroot to switch from a 
ram image root to a cgd based root. This allows me to have the cgd 
parameters physically separated from the computer in question. This 
solution is not perfect, as it doesn't appear to work on NetBSD/amd64 
when booting from an USB memory key (see PR 36963).

    In a previous discussion concerning this particular bug, Thor 
Lancelot Simon expressed some skepticism about the way init.chroot is 
implemented, so I started thinking about alternative ways to implement 
"root on cgd".

    I've been looking into if it's possible to hard code the cgd 
parameters in a kernel configuration, and tell the kernel to mount root 
on a cgd-device. The goal is to be able to have the cgd parameters 
physically separated from the rest of the system (apart from the

(Continue reading)

Thor Lancelot Simon | 23 Mar 2009 21:16

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, Mar 23, 2009 at 09:10:40PM +0100, Jan Danielsson wrote:
>
>    I've been looking into if it's possible to hard code the cgd  
> parameters in a kernel configuration, and tell the kernel to mount root  
> on a cgd-device. The goal is to be able to have the cgd parameters  
> physically separated from the rest of the system (apart from the  
> parameters in ram). Unfortunately, work has been keeping me too busy to  
> put any real effort into it. I might just as well ask here; would it be  
> possible to boot a kernel, which is hardcoded to use cgd0 as a root, off  
> a USB memory key? Obviously the kernel will need to configure the cgd0  
> device prior to mounting root, which may be a source of difficulties.

Yes.  I hadn't considered the possibility of compiling the cgd parameters
into the kernel.  In that case, it's very easy.

You have to provide a way to compile the cgd parameters into the kernel,
and write a mountroothook which sets up the cgd.  Then it ought to just
work.

The cgd parameters could probably even be passed by the boot loader
as kernel arguments.  Then this could even work with a generic kernel,
and be set up at install time.

Thor

Jan Danielsson | 23 Mar 2009 21:37

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

Thor Lancelot Simon wrote:
>>    I've been looking into if it's possible to hard code the cgd  
>> parameters in a kernel configuration, and tell the kernel to mount root  
>> on a cgd-device. The goal is to be able to have the cgd parameters  
>> physically separated from the rest of the system (apart from the  
>> parameters in ram). Unfortunately, work has been keeping me too busy to  
>> put any real effort into it. I might just as well ask here; would it be  
>> possible to boot a kernel, which is hardcoded to use cgd0 as a root, off  
>> a USB memory key? Obviously the kernel will need to configure the cgd0  
>> device prior to mounting root, which may be a source of difficulties.
> 
> Yes.  I hadn't considered the possibility of compiling the cgd parameters
> into the kernel.  In that case, it's very easy.
> 
> You have to provide a way to compile the cgd parameters into the kernel,
> and write a mountroothook which sets up the cgd.  Then it ought to just
> work.

    Excellent. I have a rough idea about where I need to dig around to 
get this done. Unless it is to become a GSoC project, I'll allocate some 
time for this and start working on it more seriously.

> The cgd parameters could probably even be passed by the boot loader
> as kernel arguments.  Then this could even work with a generic kernel,
> and be set up at install time.

    The cgd parameters contains a salt value. Is it possible to store 
such arguments in a file separated from the kernel? It doesn't seem 
feasible for the user to enter these values manually each boot.

(Continue reading)

Thor Lancelot Simon | 23 Mar 2009 21:48

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, Mar 23, 2009 at 09:37:54PM +0100, Jan Danielsson wrote:
>
>    The cgd parameters contains a salt value. Is it possible to store  
> such arguments in a file separated from the kernel? It doesn't seem  
> feasible for the user to enter these values manually each boot.

The boot loader already gets the kernel arguments from a configuration
file.  At least when booting in multiboot mode, many arguments -- perhaps
an arbitrary number? -- of reasonably large size are supported.

Thor

Roland Dowdeswell | 23 Mar 2009 21:47

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On 1237840674 seconds since the Beginning of the UNIX epoch
Jan Danielsson wrote:
>

>> The cgd parameters could probably even be passed by the boot loader
>> as kernel arguments.  Then this could even work with a generic kernel,
>> and be set up at install time.
>
>    The cgd parameters contains a salt value. Is it possible to store
>such arguments in a file separated from the kernel? It doesn't seem
>feasible for the user to enter these values manually each boot.

Also, you want to be able to deal with some of the potential
complixity that can be expressed in the parameters file.  One of
the reasons that I specifically did not choose an on the disk format
was so that the file could be extended to do such things as exec'ing
external programs to fetch keys from a central key authority.  Or
talking to an arbitrary number of key servers, etc.

Now, granted, you will not be able to have the boot blocks do most
of the more interesting features that cgdconfig(8) can do because
you lack, well, a kernel, but you do want to at least be able to
accept multiple key generation blocks instead of just a single one.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

Jan Danielsson | 24 Mar 2009 08:14

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

Roland Dowdeswell wrote:
> On 1237840674 seconds since the Beginning of the UNIX epoch
> Jan Danielsson wrote:
> 
>>> The cgd parameters could probably even be passed by the boot loader
>>> as kernel arguments.  Then this could even work with a generic kernel,
>>> and be set up at install time.
>>    The cgd parameters contains a salt value. Is it possible to store
>> such arguments in a file separated from the kernel? It doesn't seem
>> feasible for the user to enter these values manually each boot.
> 
> Also, you want to be able to deal with some of the potential
> complixity that can be expressed in the parameters file.  One of
> the reasons that I specifically did not choose an on the disk format
> was so that the file could be extended to do such things as exec'ing
> external programs to fetch keys from a central key authority.  Or
> talking to an arbitrary number of key servers, etc.
> 
> Now, granted, you will not be able to have the boot blocks do most
> of the more interesting features that cgdconfig(8) can do because
> you lack, well, a kernel, but you do want to at least be able to
> accept multiple key generation blocks instead of just a single one.

    Yes; I'd already given that some thought. My goal is to keep as much 
of cgdconfig's flexibility as possible. Although I don't immediately see 
any way to provide keys from different sources, I don't want to break 
the possibility to use N-factor keys, in case someone finds a way.

    Hmm.. Thinking a little more about it, it's pretty trivial to get 
access to physically separated keys -- which the kernel could access

(Continue reading)

Jan Schaumann | 23 Mar 2009 21:44

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

Jan Danielsson <jan.m.danielsson <at> gmail.com> wrote:

>    Excellent. I have a rough idea about where I need to dig around to get 
> this done. Unless it is to become a GSoC project, I'll allocate some time 
> for this and start working on it more seriously.

One should not preclude the other.  That is, don't let the project
possibly being added as a suggested SoC project prevent you from
starting to work on it and likewise your work on it should not prevent
it from being added as a possible SoC project.

-Jan

Todd Vierling | 23 Mar 2009 18:33

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, Mar 23, 2009 at 12:54 PM, David Brownlee <abs <at> netbsd.org> wrote:
>> Without something like TPM, doesn't solve the unattended server
>> problem, though perhaps that does require a more complex solution
>> (such as a ramdisk or small root partition, over which / is remounted)
>> to allow the key to be stored in a more flexible manner.

>        Could you clarify how the latter would work - is the intention
>        to allow the system to boot up to a point where the administrator
>        can connect in to finish cgd configuration and remount?

No, it's much more simplistic than that -- storage of a (possibly
partial) key on a removable device so that the machine can fully start
unattended, but only with the extra media device in place.  Sort of a
"poor man's TPM".  This provides some of the benefits of encryption,
such as in-built resistance to media-level data forensics, and
unreadability of the physical disk outside of the machine in which it
was installed.  The idea is to make a common attacker (someone who
might run off with a pulled-out drive) eventually not so common.

I've accomplished the more complicated setup you describe with a
remount of / (done using ssh over Tor, no less) but it's just way too
painful for words.  You'd be better off with a serial-capable BIOS or
a Weasel and ssh'able console server in that case.  (Or as an
alternative, a basic boot system with the base OS to be used at full
runtime, but with /home, most of /var, /tmp, and other writable areas
on a manually mounted cgd; that would not require a remount of /.)

--

-- 
-- Todd Vierling <tv <at> duh.org> <tv <at> pobox.com> <todd <at> vierling.name>

(Continue reading)

David Brownlee | 23 Mar 2009 18:49

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, 23 Mar 2009, Todd Vierling wrote:

> On Mon, Mar 23, 2009 at 12:54 PM, David Brownlee <abs <at> netbsd.org> wrote:
>>> Without something like TPM, doesn't solve the unattended server
>>> problem, though perhaps that does require a more complex solution
>>> (such as a ramdisk or small root partition, over which / is remounted)
>>> to allow the key to be stored in a more flexible manner.
>
>>        Could you clarify how the latter would work - is the intention
>>        to allow the system to boot up to a point where the administrator
>>        can connect in to finish cgd configuration and remount?
>
> No, it's much more simplistic than that -- storage of a (possibly
> partial) key on a removable device so that the machine can fully start
> unattended, but only with the extra media device in place.  Sort of a
> "poor man's TPM".  This provides some of the benefits of encryption,
> such as in-built resistance to media-level data forensics, and
> unreadability of the physical disk outside of the machine in which it
> was installed.  The idea is to make a common attacker (someone who
> might run off with a pulled-out drive) eventually not so common.

 	Then at the risk of feeping creatures... why can't the boot block
 	do that? Either the bootblocks and external config lie on the
 	USBkey or similar and then it configures the cgd on the main
 	disk and then loads the kernel from it, or the bootblocks can
 	read some additional config from the USBkey before mounting
 	the main cgd, and even better can pass that extra data across
 	to the kernel...

--

--

(Continue reading)

Thor Lancelot Simon | 23 Mar 2009 19:00

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, Mar 23, 2009 at 05:49:15PM +0000, David Brownlee wrote:
>
> 	Then at the risk of feeping creatures... why can't the boot block
> 	do that? Either the bootblocks and external config lie on the

It can, I think -- at the cost of keeping the kernel-to-boot on the USB
key.  This isn't a "pivot root" setup, it's more like booting from the
network but using a local filesystem -- the kernel needs to be told to
run a mountroothook which sets up the cgd with the specified key, and
to use it as root.

You probably need to ensure, somehow, that the USB key can be neither
read nor written while the system is up.

Thor

Todd Vierling | 23 Mar 2009 18:37

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, Mar 23, 2009 at 1:33 PM, Todd Vierling <tv <at> netbsd.org> wrote:
> (Or as an
> alternative, a basic boot system with the base OS to be used at full
> runtime, but with /home, most of /var, /tmp, and other writable areas
> on a manually mounted cgd; that would not require a remount of /.)

Thinko....  s:/tmp:swap:

In a setup like this, you'd want /tmp (and possibly parts of /var) on
a ramdisk, and swap not added until cgd mount time.

--

-- 
-- Todd Vierling <tv <at> duh.org> <tv <at> pobox.com> <todd <at> vierling.name>

Cem Kayali | 23 Mar 2009 18:10

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

Hi,

FreeBSD allows encryption of root partition and may be good start.

http://events.ccc.de/congress/2005/fahrplan/attachments/586-paper_Complete_Hard_Disk_Encryption.pdf

I have tried that approach about a year ago and successfully performed 
installation. Also discussed with author, Marc Schiesser, because 
tutorial should be updated according to FreeBSD 7.x and 8.x versions. I 
have these notes in my archive.

Basic idea is that:

1- Run fixit disc of FreeBSD which is a live-cd with various FreeBSD 
(own) utilities. Dont forget to load geom_eli module.

2- Partition the hard drive, and then, create geli slices (partitions).

3- Run sysinstall and address the geli partitions as install target. 
Everything is isntalled into geli partition.

4- Once finished the work, copy kernel, kernel modules to ie; a usb ram. 
In other words, prepare boot-only usb disk

5- Once everything is complete, boot from usb. It asks passphrase of 
geli slice and mounts geli root as root

6- Remove usb ram.

Regards,

(Continue reading)

David Brownlee | 23 Mar 2009 18:19

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, 23 Mar 2009, Cem Kayali wrote:

> Hi,
>
> FreeBSD allows encryption of root partition and may be good start.
>
> http://events.ccc.de/congress/2005/fahrplan/attachments/586-paper_Complete_Hard_Disk_Encryption.pdf
>
> I have tried that approach about a year ago and successfully performed 
> installation. Also discussed with author, Marc Schiesser, because tutorial 
> should be updated according to FreeBSD 7.x and 8.x versions. I have these 
> notes in my archive.
>
>
> Basic idea is that:
>
> 1- Run fixit disc of FreeBSD which is a live-cd with various FreeBSD (own) 
> utilities. Dont forget to load geom_eli module.
>
> 2- Partition the hard drive, and then, create geli slices (partitions).
>
> 3- Run sysinstall and address the geli partitions as install target. 
> Everything is isntalled into geli partition.
>
> 4- Once finished the work, copy kernel, kernel modules to ie; a usb ram. In 
> other words, prepare boot-only usb disk
>
> 5- Once everything is complete, boot from usb. It asks passphrase of geli 
> slice and mounts geli root as root
>

(Continue reading)

Cem Kayali | 23 Mar 2009 18:23

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

David Brownlee, 03/23/09 19:19:
> On Mon, 23 Mar 2009, Cem Kayali wrote:
>
>> Hi,
>>
>> FreeBSD allows encryption of root partition and may be good start.
>>
>>
http://events.ccc.de/congress/2005/fahrplan/attachments/586-paper_Complete_Hard_Disk_Encryption.pdf 
>>
>>
>> I have tried that approach about a year ago and successfully 
>> performed installation. Also discussed with author, Marc Schiesser, 
>> because tutorial should be updated according to FreeBSD 7.x and 8.x 
>> versions. I have these notes in my archive.
>>
>>
>> Basic idea is that:
>>
>> 1- Run fixit disc of FreeBSD which is a live-cd with various FreeBSD 
>> (own) utilities. Dont forget to load geom_eli module.
>>
>> 2- Partition the hard drive, and then, create geli slices (partitions).
>>
>> 3- Run sysinstall and address the geli partitions as install target. 
>> Everything is isntalled into geli partition.
>>
>> 4- Once finished the work, copy kernel, kernel modules to ie; a usb 
>> ram. In other words, prepare boot-only usb disk
>>

(Continue reading)

Thor Lancelot Simon | 23 Mar 2009 19:51

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, Mar 23, 2009 at 07:23:00PM +0200, Cem Kayali wrote:
>
> 'I think' auto-configured (or enabled as option by default while  
> installing), CGD or similar encrypted partitions is not allowed by US  
> laws... It should be done manually.

Can you please explain why you believe that?

If you don't have any rational basis for believing it, could you please be
more careful when making similar claims in the future?

I see these strange quote marks around 'I think' in your text.  I'm not
sure what they're meant to indicate, but if they are meant to indicate
that you are advocating that other people do things on the basis of a claim
whose truth value even you are highly skeptical of, perhaps you should try
to avoid making such claims.  If that's not what they're meant to indicate,
I do not know what they mean and I wish you would be more clear.

Thor

Cem Kayali | 23 Mar 2009 20:50

Picon

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

Thor Lancelot Simon, 03/23/09 20:51:
> On Mon, Mar 23, 2009 at 07:23:00PM +0200, Cem Kayali wrote:
>   
>> 'I think' auto-configured (or enabled as option by default while  
>> installing), CGD or similar encrypted partitions is not allowed by US  
>> laws... It should be done manually.
>> Can you please explain why you believe that?
>>
>> If you don't have any rational basis for believing it, could you please be
>> more careful when making similar claims in the future?
>>
>> I see these strange quote marks around 'I think' in your text.  I'm not
>> sure what they're meant to indicate, but if they are meant to indicate
>> that you are advocating that other people do things on the basis of a claim
>> whose truth value even you are highly skeptical of, perhaps you should try
>> to avoid making such claims.  If that's not what they're meant to indicate,
>> I do not know what they mean and I wish you would be more clear.
>>
>> Thor

I said 'I think' because i read somewhere that neither FreeBSD nor 
NetBSD can offer disk encryption by default. "By default" means, easy to 
setup via ie; sysinstall or install disk.

I need to get help from Google to find it again. Untill that - ignore then.

Regards,
Cem

(Continue reading)

Steven M. Bellovin | 23 Mar 2009 20:36

Re: cgd (encrypted disk) support in bootblocks (Was: summer of code - scrub feature)

On Mon, 23 Mar 2009 19:23:00 +0200
Cem Kayali <cemkayali <at> eticaret.com.tr> wrote:

> 'I think' auto-configured (or enabled as option by default while 
> installing), CGD or similar encrypted partitions is not allowed by US 
> laws... It should be done manually.

I know of no US law that would prohibit this.  More broadly, I know of
no US law that restricts use of cryptography in any way.  I also
believe that as an open source project, there aren't even any export
restrictions, though I'm much less sure about that.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

Return

Return to gmane.os.netbsd.devel.security.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane