Encrypted pup_save for Puppy 212

[John Doe]

Using the Ext2 IFS Drivers for Windows and FreeOTFE, I just mounted the pup_save image I made in Puppy with LUKS from XP.

Pretty Cool

[PaulBx1]

Well, that's something!

I was looking at your crypt-pupsave, getting confused about your statement you only modified option 1. Then I realized I had a bug in there.

Look at the variable CRYPT_OPTION. In the verbiage I call the empty encrypted pupsave CRYPT_OPTION = 1, and then use it as if it was supposed to be CRYPT_OPTION =3 everywhere.

To fix, find where the variable is used, and change 3 to 1 and vice versa. And where CRYPT_OPTION is set up, revise the case statement (just make an explicit case for each of 0, 1, 2 and 3).

BTW, just a nit on that block 2 of kirk's boot code, the text color needs to be set back to white at the end; the red color ends up being used for later non-encryption text. Actually, it might not be needed to set it to red in the first place.

So is this everything I need to try out the LUKS regime? I want to check this out too.

I think we just will have to offer a package, petget or whatever (not sure if that works for new initrd or new vmlinuz, if that's what's involved). If you can set this package up I will be willing to keep it up to date, if you don't want to do that. I guess that is all that will work given the size of the thing, unless we (or you, ha ha) want to go back and do the whole thing again with loop-aes and put it into zdrv (if in fact that will work out that way, which we don't know at this point).

Is there any modification to initrd.gz, outside of those two blocks of code kirk cooked up? If not, then we can get Barry to put that in the standard Puppy, which should help. And those modules in zdrv of course.

Or am I missing something? Have you got it down so that a user not interested in encryption will not see a big size increase in Puppy?

[John Doe]

Then I realized I had a bug in there.

I saw that. As a programmer I wouldn't go so far as calling that a bug, but just some strange code. It did actually work after all.

BTW, just a nit on that block 2 of kirk's boot code...

The next block in initrd handles that switch back to white. Although with the way this looks, that color change will probably get pulled anyway. From what I can tell the password HAS to be piped into cryptosetup and I tried read with the -s switch and it puked. Without the switch the password shows up on the screen as plain text. I'm hoping one of the guru's around here can mention some neat way to point the 'read' screen output at /dev/null and still read the input. Another alternative would be to drop 'dialog' in the bin, for a password box (I've got a tested mock up of this method going under bash with the pipe).

So is this everything I need to try out the LUKS regime? I want to check this out too.

Yes, you've got pretty much everything I've got there (I added two more scripts earlier tonight that worked for testing mounting and unmounting). The booting still doesn't work, but LUKS does run under puppy (after the modules are loaded) and seems to make images and mount them ok.

One quick note to the wise on LUKS and FreeOTFE. One seems to be able to mount linux images under windows and linux, but not mount windows images under linux; therefore it is best practice to make a linux image if one wants to interop.

Is there any modification to initrd.gz, outside of those two blocks of code kirk cooked up? If not, then we can get Barry to put that in the standard Puppy, which should help.

yes and I'm getting rather confused with it. I've been generating errors for two days, sometimes even a kernel panic when I really botch it (note to self: do NOT nest a function inside another function, duh..).

I did manage to find ;check_status $? which I added onto the mount line and it keeps telling me it can't find cryptsetup (although I copied it to /bin and /usr/sbin [and added a path to there]. I did have it found for while and was getting a permission denied error which lead me to believe that the password wasn't piping correctly. At the time I had it at both /bin and /usr/sbin with path mods. I've very confused at this point.

And those modules in zdrv of course.

Actually the two I posted (dm-mod and dm-crypt) are not in the zdrv. I'm hoping Barry will consider adding them.

back-track...

regarding the dm-crypt vs. CryptoLoop debate, I found some info here:

http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt

note the part that says, "All in all, it [Loop-AES] ought to be the leader of the pack, except for one thing: Through politics and in-fighting the Loop-AES developers have alienated the Linux kernel team, including Linus himself. As a result loop-AES is not supported by the mainline Linux kernel..."

makes me wonder what the truth is.

[PaulBx1]

Ah, politics. Always the most important thing. Funny, I think the main proponent of loop-AES is a Finn, just like Linus is. That's a good link by the way; it's always nice to see competently-written material.

Actually the two I posted (dm-mod and dm-crypt) are not in the zdrv. I'm hoping Barry will consider adding them.

What I meant was, I don't think Barry will have any issue with small script changes with initrd.gz, and I doubt he minds zdrv ballooning out either, since only the parts the user wants get loaded. It's the standard, vanilla Puppy core that can't grow much. The more of this we can shove into zdrv, the better. Isn't that an option with some of this? You can build one way (modify the kernel, say) or another way (as loadable modules)?

Maybe on your boot difficulties, ask Barry since he knows a lot about booting! Or see how he handles reading input at the early part of the boot asking for the boot parameters like pfix=ram. There might be some special thing to do when the boot is at an early level like this. In fact it might even make sense to read the passphrase at that point...

As to my bug/"strange code", I don't really like strange code, so feel free to make it less strange.

[John Doe]

@Paul thoughtful reply tomorrow.

@Everyone, this is where I'm stuck.

Using the code and method here:
http://www.murga-linux.com/puppy/viewto ... 4588#84588

I see the picture below.

I'm confused as to whether the error means there is a permission issue with the executable, creation of the block device or it's an indication that the password is not being piped correctly.

Can anyone help? Can anyone tell me how to edit the initrd error function in order to bail out to a prompt?

[PaulBx1]

What permissions do you have on the pup_save? Are there permissions on loop devices by any chance?

I notice you have the journal daemon reporting some messages. Maybe it's time to try mounting the pup_save as ext2. There are warnings everywhere not to use ext3 on a loop file, and maybe dm-crypt actually enforces this prohibition. See this thread:

http://www.murga-linux.com/puppy/viewtopic.php?t=13508

Barry is now considering going back to ext2 for pup_saves on release 2.13.

BTW, what does error "1103" mean? Is there some place where error messages are described?

<later> Woops, I checked my own log and it has the same messages:
sh-3.00# cat bootkernel.log |grep mount
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3-fs: mounted filesystem with ordered data mode.

Oh, well, maybe that's "normal". Still, probably worth trying ext2 to see if you have any more luck.

[PaulBx1]

Been looking around with google, here are a few things, probably nothing you don't already know about:

A script to mount a loop device with LUKS:

Code: Select all

# Mount filesystem:
# Create loop device attached to encrypted source file:
if losetup $LOOP_DEV $ENC_SRC; then
   # Create LUKS Crypt device:
   #cryptsetup luksDump $LOOP_DEV
   echo "Enter password to unlock encrypted volume \"$ENC_SRC\":"
   if cryptsetup luksOpen $LOOP_DEV $ENC_DEV_NAME; then
      #dmsetup table
      #cryptsetup status $ENC_DEV[_NAME]
      # Mount the encrypted filesystem device:
      if mount $ENC_DEV $ENC_DST; then
         #echo "Mount apparently successful ($ENC_SRC, $LOOP_DEV, $ENC_DEV_NAME, $ENC_DST)."
         echo "Mount apparently successful."

The script itself might be useful, but I just posted the above which is part of it, to show how it's done - probably what you are doing already...
http://www.saout.de/tikiwiki/tiki-index ... e=luksopen


Another note about password processing:

NOTES ON PASSWORD PROCESSING FOR REGULAR MAPPINGS
From a file descriptor or a terminal: Password processing is new-line sensitive, meaning the reading will stop after encountering \n. It will processed the read material with the default hash or the hash given by --hash. After hashing it will be cropped to the key size given by -s (or default 256bit).

From a key file: It will be cropped to the size given by -s. If there is insufficient key material in the key file, cryptsetup will quit with an error.
NOTES ON PASSWORD PROCESSING FOR LUKS
Password processing is totally different for LUKS. LUKS uses PBKDF2 to protect against dictionary attacks (see RFC 2898). LUKS will always use SHA1 in HMAC mode, and no other mode is supported at the moment. Hence, -h is ignored.

LUKS will always do an exhaustive password reading. Hence, password can not be read from /dev/random, /dev/zero or any other stream, that does not terminate.

LUKS saves the processing options when a password is set to the respective key slot. Therefore, no options can be given to luksOpen. For any password creation action (luksAddKey, or luksFormat), the user specify, how much the time the password processing should consume. Increasing the time will lead to a more secure password, but also will take luksOpen longer to complete. The default setting of one second is sufficient for good security.

http://www.die.net/doc/linux/man/man8/cryptsetup.8.html

That is from the cryptsetup man page. Just grasping at straws here, in case it might shed light on anything (perhaps your error only means the password is wrong!). I suppose you know that, in your comment about piping it properly.

BTW, did you use the --verify-passphrase switch when you created the file in the first place?

I notice in your block 1 of the init code, you load various things but not hashalot. Doesn't the processing of the passphrase depend on the hash module being there?

But then I see:

For the passphrase hash algorithm, no modules need to be loaded, since it is included by cryptsetup from a user space library.

However:

Modprobe the dm-crypt and the cipher (the module name is the part of the cipher name before the first hyphen). If the cipher block mode needs a hash, load that too. Note that the cipher block mode hash is something different from the passphrase hash: it's the part after the colon in eg 'aes-cbc-essiv:sha256'.

http://yaird.alioth.debian.org/yaird.html#crypto

[John Doe]

What permissions do you have on the pup_save?

It's on a fat16 usb flash stick. No ACL of any kind.

Are there permissions on loop devices by any chance?

None that I know of. I think loop devices just treat the file as a blob of bits.

Barry is now considering going back to ext2 for pup_saves on release 2.13.

I saw that. I was going to make one last objective observation in that post.

BTW, what does error "1103" mean? Is there some place where error messages are described?

Best I can tell it correlates to the line number in initrd, but is not the line number in initrd. I speculate that it is the number of the command going through the processor, but that isn't necessarily the level of the OSI model I work in.

journaling message...maybe that's "normal"....worth trying ext2...

Agreed.

###

I think that the main problem is that cryptsetup doesn't seem to interact with the shell like losetup did. losetup was kind enough to actually ask for input, cyptsetup does NOT stop the execution and ask for input under busybox. It DOES under bash.

[John Doe]

...probably nothing you don't already know about

Don't worry, I feel as lost as you said you were.

...to show how it's done...

That's the interesting thing here. I've seen the redhat, gentoo and debian implementations but still can't make it work here. I've also sucessfully generated, mounted and unmounted a LUKS encrypted file but I can only do it from the bash shell and not at boot.

Password processing is new-line sensitive, meaning the reading will stop after encountering \n.

password can not be read from...stream...that does not terminate

Looks like I should stop typing -n in there.

...I suppose you know that, in your comment about piping it properly.

I did get it to work with a script using a pipe.

BTW, did you use the --verify-passphrase switch when you created the file in the first place?

Yes. I used a "four letter word" that I don't type often.

it's the part after the colon in eg 'aes-cbc-essiv:sha256'

Ah! I've now notice that cyptsetup loads module sha256 automatically when I run it under bash. I added that to initrid.gz and loaded it, but still no luck.

More soon

[PaulBx1]

I've seen the redhat, gentoo and debian implementations but still can't make it work here. I've also sucessfully generated, mounted and unmounted a LUKS encrypted file but I can only do it from the bash shell and not at boot.

Do you happen to know if redhat, gentoo or debian use bash during boot (is that even possible)? Could we call a bash script during that small portion of the boot when loading the pup_save? I suppose bash would have to be made part of the initrd then...

I'm a little confused about shells. The book I have says the bourne shell does not offer command-line editing, but I can edit my command line. Yet "echo $SHELL" yields "sh". So does Puppy use the bourne shell or not?

Also, you say you can mount, etc from the bash shell but not at boot. Can you mount, not at boot, using the bourne shell (correction: default Puppy ash shell)? It seems it would be easier to try to get that working first than to wrestle with the boot process...

I used a "four letter word" that I don't type often.

I think cryptoloop enforced a 20-character minimum; thought I read that, anyway. I'm surprised dm-crypt lets you get away with 4 characters. Or did you say the naughty word several times? It's hard to imagine a scenario where it doesn't mind under the bash shell but does with sh.

[Gn2]

So does Puppy use the bourne shell or not?

Code: Select all

env 
bash -v

Puppy sets profile - see your home variable - It also uses
BusyBox<> ASH
NOT the full shell CLI environment.

Could we call a bash script during

Advanced Bash Scripting Guide

Code: Select all

Chapter
34.1

If a script needs to test whether it is running in an interactive shell, it is simply a matter of finding whether the
prompt variable, $PS1
is set. (If the user is being prompted for input, then the script needs to display a prompt.)
1 if [ -z $PS1 ] # no prompt?
2 then
3 # non-interactive
4 ...
5 else
6 # interactive
7 ...
8 fi
Alternatively, the script can test for the presence of option "i" in the $- flag.
1 case $- in
2 *i*) # interactive shell
3 ;;
4 *) # non-interactive shell
5 ;;
6 # (Courtesy of "UNIX F.A.Q.," 1993)

An initrd is NOT Req'd to boot the kernel - Puppy needs the RAM image support for running in liveCD & Frugal.
All part of the mastering scripts.

Do you want to master own initial RAM boot image ?
Please see relevant documentation
Any service started after the boot must be started by coded subsequent events
This is standard Linux behaviour -

The secondary, or second-stage, boot loader could be more aptly called the kernel loader.
The task at this stage is to load the Linux kernel and OPTIONAL initial RAM disk

Please review
Syslinux
And entire Boot Process
Especially INITRD

[PaulBx1]

Well, I'm not going to try talking Barry into dumping initrd, however optional it may be! You're welcome to try if you want. And no, I don't want to have an initrd that is non-standard either. So the question remains, is bash available now in initrd? I guess not since /initrd/bin does not hold it. And since /bin/bash is half a megabyte, I'm guessing bash won't be put into initrd any time soon.

Another question I have, is whether it can happen that cryptsetup requires to be executed by bash? Haven't found out yet. I don't even know if it is a script, maybe it has #!/bin/bash on top of it. If so, we are screwed.

The error message doesn't seem to point to that, but error messages are often deceiving.

So, it looks like we are back to using ash/busybox to run cryptsetup (if possible). It's looking like it is missing something; if cryptsetup is a script maybe it calls some function that is truncated by busybox, so we need to add some -FULL version of a command to /initrd/bin.

On a separate topic:

The tinfoil-hat brigade among us has probably noticed by now the gaping security hole that an unencrypted /boot presents. Indeed, someone with physical access to the machine could quite concievably taint the kernel, replace cryptsetup with a keylogging clone, or all manner of clandestine actions designed to gain access to your encrypted data.

http://www.wuglug.org.uk/tutorials/kernel/devmapper

This is just a reminder to myself for a future project, assuming dm-crypt works. Perhaps a small script to run md5sums on vmlinuz, etc., compared with values stored within the pup_save, will take care of this issue.

[PaulBx1]

Here is a wrapper script that calls cryptsetup. It uses "#!/bin/sh".

http://www.solsys.org/mod/faq/getdata.php?id=99

It was found here:
http://www.solsys.org/mod.php?mod=faq&op=view&id=103

[Gn2]

missing something;

Code: Select all

PHYSICAL  ACCESS 

If above is possible > ALL other security precautions are a waste of effort

talking Barry into dumping initrd, however optional it may be! You're welcome to try

What ..... would ever prompt that line of thought ?

For more practical methods of coping with rooting attempts -
OR more common daily usage scenarios - You may find it of use to :
Research sub-netting, automated cron usage & Honey-Pots.
Only access WEB via masked proxies &/or onion routers.
Encrypting is tantamount to locking the door after the fact.
Like all locks - that only hinders/slows, NOT stops.

It is a good bet - many are still not using Rkhunter, Stack Protection or cron'ed backups
(Can be Cfg'd to concatenate changes only)
Is your MBR tables backed up ?

[PaulBx1]

Why are you doing this? We are trying to get some one thing working, not trying to solve every possible security issue with one blow. I just made a reminder to myself to look at the next issue when this is done. I also have to think about swap. And suspend. And so forth. All in good time...

Here is a page that suggests busybox needs a patch to support cryptsetup. There doesn't seem to be any detail, but this is clearly something worth chasing down.
http://bugs.busybox.net/view.php?id=838

Here is a tutorial about using initrd, busybox, ash, cryptsetup, LUKS, all the stuff we are trying. Maybe something in there will be of use. At least it shows that somebody has actually used this combination:
http://www.loria.fr/~gustedt/early/


<later>
I'm now getting the impression that patch was to add cryptsetup itself to busybox. Apparently it has not yet been added, and it is also not for LUKS. So never mind, false alarm...

[Gn2]

Why are you doing this?

Several questions were posted - they were answered.

How Puppy variances apply : Bash - boot processes - creating initiate ram images.

It wil be noted - no non- relevant links were supplied.

> I forgot to mention that Barry will have to add this
> There is a limit to how much we can talk Barry into adding.
> We'll have to wait for Barry to say something
> Maybe Barry should just throw the origninal method into the next beta
> The thing is, I'm hoping to get this encryption into
> I don't think Barry will have any issue with small script changes with initrd.gz, the standard Puppy

[PaulBx1]

John, you might be interested in this code fragment in that tutorial I last mentioned, the one that seems most relevant to the Puppy boot process:

Code: Select all

 
#!/bin/sh
...
while [ -n "${maps}" ]; do
    local remaining=

    findKey

    if [ ! -e "${key}" ]; then
        # boot up will halt here until a key is typed in
        read -s -p "LUKS passphrase for ${maps}: " passwd
        echo
        echo -n "${passwd}" > "${key}"
    fi

    echo -n "creating maps in /dev/mapper/.." 
    for map in ${maps} ; do
        dev=$(subst 's|^[^/].*|/dev/&|' "${map}")
        map=$(basename "${dev}")
        if ! silent /bin/cryptsetup -q --key-file="${key}" luksOpen "${dev}" "${map}"; then
	    echo -n "[${map}]."
            remaining="${remaining} ${map}"
	else
	    echo -n "${map}."
        fi
    done
    echo "done."
    rm -f "${key}"
    maps="${remaining}"
  done

http://www.loria.fr/~gustedt/early/initscript

He also made this interesting comment:

Now you should be asked a passphrase and the device should be mapped. If something goes wrong here, maybe you have the wrong cryptsetup or you forgot to add the `-s' option for read in the busybox shell executable.

http://www.loria.fr/~gustedt/early/

read -s works when I try it from the command line... of course that is "read" from a booted-up puppy. Who knows how it works from initrd. The busybox from the two places is different, of course.

BTW, I nagged Barry that our busybox is quite old (1.0.1 vs the current 1.3.0, with many bugfixes). Also older than the one this fellow used, 1.1.3. Maybe I mentioned that already. I suppose another line of attack would be to build the latest busybox and stick it in the initrd, just to see if that fixes anything (don't bother cutting it down). Sounds like work though.

[John Doe]

Thanks for the links Gn2. There was some really good info in there.

[John Doe]

BTW, I nagged Barry that our busybox is quite old (1.0.1 vs the current 1.3.0, with many bugfixes). Also older than the one this fellow used, 1.1.3. Maybe I mentioned that already. I suppose another line of attack would be to build the latest busybox and stick it in the initrd, just to see if that fixes anything (don't bother cutting it down). Sounds like work though.

Don't nag him too much. I'm sure he'd like to, as he could slim down initrd.gz even more. Puppy's init has some problems with the newer busybox. I've been sitting here compiling and testing for the last 10 hours. btw, I'd recommend shooting for 1.2.2.1 as an upgrade target. 1.3.0 has about 10 patches already.

I've started narrowing the problem (with puppy and busybox specifically) down. Right after "Looking for Puppy in.." it dies. /tmp/bootinit.log says there is an operand error.

I don't think ash likes this 'NOT' like this now:
if [ ! "`echo "$TESTPARTS" | grep "iso9660"`" = "" ];then

I think bottom like is this LUKS booting idea has got to wait until Busybox is upgraded.

This could take a while

[PaulBx1]

So John, where does that statement come from? Can it be dismantled and simplified to the point it starts working again?

What is "TESTPARTS"? I want to try that statement at the command line.