Date: Fri, 10 Sep 2004 12:15:49 -0400 From: Allan Fields <bsd@afields.ca> To: "R. W." <list-freebsd-2004@morbius.sent.com> Cc: freebsd-geom@freebsd.org Subject: Re: Attaching two gbde partitions with the same password Message-ID: <20040910161549.GK34157@afields.ca> In-Reply-To: <200409091517.39846.list-freebsd-2004@morbius.sent.com> References: <200409050234.13571.list-freebsd-2004@morbius.sent.com> <20040907080941.GH34157@afields.ca> <20040907082311.GI34157@afields.ca> <200409091517.39846.list-freebsd-2004@morbius.sent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 09, 2004 at 03:17:39PM +0100, R. W. wrote:
> On Tuesday 07 September 2004 09:23, Allan Fields wrote:
> > Add lines below to the examples (in case $pass hangs around.)
> >
> > On Tue, Sep 07, 2004 at 04:09:41AM -0400, Allan Fields wrote:
> > > The only issue with reading in passwords from a shell script is to
> > > not echo to the tty. There are ways around this problem such as:
> > >
> > > In bash you can use:
> > > read -esp "Enter passphrase: " pass
> > > gbde attach $dev -l $lck -p $pass
> >
> > gbde attach $dev2 -l $lck2 -p $pass
> > pass=`head -c1024 /dev/urandom`; unset pass
> >
> > > otherwise:
> > > tmp=`stty -g`; stty -echo
> > > read -p "Enter passphrase: " pass
> > > echo; stty $tmp
> > > gbde attach $dev -l $lck -p $pass
> >
> > gbde attach $dev2 -l $lck2 -p $pass
> > pass=`head -c1024 /dev/urandom`; unset pass
> >
> > > You could put this into your rc.early or something similarly early
> > > in the boot sequence if it suits your needs. (For security reasons
> > > passing the passphrase on the command line should be done before
> > > going multiuser.)
>
> Thanks for your help.
>
> If I'm the only user, and I have no remote access enabled, do I gain
No network at all?
> much by attaching before going multiuser?
Pro:
- Access to volumes in later startup possible (encrypted /var and
/tmp);
- File system checks can be done along with other non-encrypted
devices;
- The machine won't be on the network at all until later in the
startup sequence;
- Potentially insecure programs other than the shell wouldn't have
had a chance to load.
Con:
- The need to enter a passphrase wouldn't work well for unattended
reboots (though you'll probably want console access for attaching
at this point anyway);
- rc scripts for attach are somewhat minimal, but this doesn't
preclude calling custom scripts early in startup, if needed;
- it's still possible for an attacker to compromise physical security
and setup logging (trojaned binaries, etc.) or monitor passphrase
entry on the keyboard.
By not putting the passphrase in the environment, it's even less
of a worry.
> > pass=`head -c1024 /dev/urandom`; unset pass
>
> I don't think this line works as intended. I had a quick look at the
> bash source, and it looks as if it allocates memory for the new string,
> and frees the old one.
That's a good point: a problem w/ most shells is that you
have lesser control than in C. You could write a wrapper program
or modify gbde(8) itself if needed. My primary intent was to quickly
ensure:
- the shell itself couldn't subsequently retrieve the old value;
- that the memory containing the passphrase was overwritten
(or at least zeroed out)
unset might be sufficient if random assignment doesn't provide
additional security in this scenario.
If the script is short lived (separate shell invocation from other
boot tasks) as with most rc scripts, the only concern is that the
passphrase could stick around in memory.
I gather the real solution here is to implement memory scrubbing upon
free() as a security feature. It would be trivial to implement: if
it hasn't been tackled, it's been on my list to look at.
Worth noting is that gbde(8) currently doesn't implement memory
scrubbing yet either.
--
Allan Fields, AFRSL - http://afields.ca
2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040910161549.GK34157>