Encrypted pup_save for Puppy 212

Under development: PCMCIA, wireless, etc.
Message
Author
PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#41 Post by PaulBx1 »

Thanks, Paul from Sweden. :) I will give that a try. I'm a real novice at these bourne scripts with x, although I've done some ksh scripts in the distant past.

I hate to say it, John, but that other approach, loop-aes, is apparently all done with loadable modules so probably would work with zdrv. :( And that would better suit the users who don't want encryption or who have small computer memories, etc. Taking up another meg or two of a small-memory machine is not going to endear us to many around here.

Perhaps I'm not understanding the whole picture, though.

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#42 Post by John Doe »

PaulBx1 wrote:I hate to say it, John, but that other approach, loop-aes, is apparently all done with loadable modules so probably would work with zdrv. :( And that would better suit the users who don't want encryption or who have small computer memories, etc. Taking up another meg or two of a small-memory machine is not going to endear us to many around here.
I got dm-mod.ko compilied and installed, it's 66k and put the rest in, I'm at this point:

Code: Select all

sh-3.00# losetup /dev/loop2 /mnt/sdb2/pup_save_crypt2.3fs
sh-3.00# cryptsetup --verbose --verify-passphrase create "CryptedVolume" /dev/loop2
Enter passphrase: 
Verify passphrase: 
Command failed: device-mapper: reload ioctl failed: Invalid argument
sh-3.00# 
I'll keep trying to press on with, "Puppy De-LUKS".

But for now perhaps you are right. Maybe Barry should just throw the origninal method into the next beta and mention that it's not the BEST but we are working on improvments.

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#43 Post by John Doe »

Just for the record, I did just get LUKS to work (really this time, not like I thought I did yesterday). I'll post more later tonight.

Code: Select all

sh-3.00# ./crypt-pupsave
libcfdisk: unable to open /dev/sda 
libcfdisk: unable to open /dev/sdb 
libcfdisk: unable to open /dev/sdc 
libcfdisk: unable to open /dev/sdd 
libcfdisk: unable to open /dev/sda 
libcfdisk: unable to open /dev/sdb 
libcfdisk: unable to open /dev/sdc 
libcfdisk: unable to open /dev/sdd 
Partion Selected:
sde1
FAT FileSystem Detected
FILENAME SET TO:
pup_save_crypt.3fs
Loading cryptoloop and aes modules
Loop Device Found:
/dev/loop2
Save File is being created, please be patient...
32768+0 records in
32768+0 records out
Save File has been created
Random Data Layer is being written, please be patient...
Syncing...
Random Data Layer has been written

WARNING!
========
This will overwrite data on /dev/loop2 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: 
Verify passphrase: 
Command successful.
Enter LUKS passphrase: 
key slot 0 unlocked.
Command successful.
Making Encrypted ext3 File System
mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
7936 inodes, 31740 blocks
1587 blocks (5.00%) reserved for the super user
First data block=1
4 block groups
8192 blocks per group, 8192 fragments per group
1984 inodes per group
Superblock backups stored on blocks: 
        8193, 24577

Writing inode tables: done                            
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
sh-3.00# 

User avatar
Carpe.Diem
Posts: 5
Joined: Fri 08 Dec 2006, 03:58

Linux LUKS Size

#44 Post by Carpe.Diem »

John Doe,

Can you say what the size of the LUKS system is that you got working?

The Windows unzipped equivalent is about 1.3 MB with ALL the cipher and hash modules included and I'm wondering how big it might make our Puppy.

While not all the modules need to be included, I would say some of them are definite MUSTS, and not just the AES competition winner alone, especially since the cipher modules vary in size from only 12 to 37 KB, and a small set would give users some judicious choices -- like the top 3 AES winners, Rijndael (what is usually termed AES by most people who are not cryptographers), Serpent, and Twofish!

Anyway, what is the Linux LUKS installed size?
[color=blue][i]...Will Puppy Penguin swat poor Butterfly? Stay tuned...[/i][/color]

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#45 Post by John Doe »

I think bottom line is that the first implimentation will be the best for puppy (unless a miracle happens here). Although this does look like it will work also, just need some help with the boot script. Perhaps Barry can use the first one and those of use on the forum will just make a second (larger) initrd.gz available or they could both be on the main site or whatever.

Luks-Modules.tar.gz has:
DM-Mod.ko (66k)
DM-Crypt.ko (15k)
'Install' is a script to install them for testing. I think one needs to run it every time you reboot unless you add the modules to modules.dep. They can be gziped for initrd.

crypt-pupsave-LUKS.tar.gz is a modified version of crypt-pupsave. Only the first "make empty crypt save" function has been modified. It also still uses the old cypto aes loop for the random data. It doesn't do the filesystem copying yet either.

Puppy-Luks.tar.gz is an alien package (2376K extracted) which can be extracted and added to the boot image and/or used as an alien package to run Luks. I've removed as much as I can. I'm hoping there are additional libraries that can be removed. I thought one could compile libraries as static and they wouldn't call each other unless they were needed. I tried this with libcrypt so I could get rid of libgpg-error all together (because I don't plan on making any errors) but it still wouldn't run without libgpg-error. There is also that lib-dietC thing (I forget the name, you know what I mean), which I don't understand how to use. It would slim off some size also.

(*edit, sorry this formating didn't work very nicely)
It contains the following:
/usr/sbin/cryptsetup 28k
/usr/sbin/dmsetup 34k
/usr/sbin/hashalot 48k
/usr/sbin/rmd160 Symlink to hashalot
/usr/sbin/sha256 Symlink to hashalot
/usr/sbin/sha384 Symlink to hashalot
/usr/sbin/sha512 Symlink to hashalot
/usr/lib/cryptsetup Empty Directory
/usr/lib/libcryptsetup.la 885B
/usr/lib/libcryptsetup.so 22B
/usr/lib/libcryptsetup.so.0 22B
/usr/lib/libcryptsetup.so.0.0.0 104K
/usr/lib/libdevmapper.so 20B
/usr/lib/libdevmapper.so.1.02 64K
/usr/lib/libgcrypt.a 1215k
/usr/lib/libgcrypt.la 847B
/usr/lib/libgcrypt.so 19B
/usr/lib/libgcrypt.so.11 19B
/usr/lib/libgcrypt.so.11.2.2 719B
/usr/lib/libgpg-error.a 65K
/usr/lib/libgpg-error.la 837B
/usr/lib/libgpg-error.so 21B
/usr/lib/libgpg-error.so.0 21B
/usr/lib/libgpg-error.so.0.3.0 37K


Latest Init Code:

These are mods on what Kirk wrote, I'll refer to them as "Block One" and "Block Two" (block two needs a bit of help still).

New Path Var:

Code: Select all

PATH="/bin:/sbin:/lib:/usr:/usr/sbin:/usr/lib"
Block One:

Code: Select all

CRYPT=$( echo $PUPSAVE | grep crypt )
 if [ "$CRYPT" != "" ] ; then
CRYPTO="yes"
zcat /lib/modules/${KERNVER}/dm-mod.ko.gz | insmod -
zcat /lib/modules/${KERNVER}/dm-crypt.ko.gz | insmod -
zcat /lib/modules/${KERNVER}/aes.ko.gz | insmod -
else
CRYPTO=""
fi
Block Two:

Code: Select all

if [ "$CRYPTO" != "" ] ; then
   echo -e "\\033[1;31m" >/dev/console
   echo "Loading encrypted pup_save_crypt" >/dev/console
   echo "" >/dev/console
   while true; do
   losetup /dev/loop1 $SMNTPT$SAVEFILE
   echo "Enter your LUKS passphrase:" >/dev/console
   read PASSPHRASE
   echo -n "$PASSPHRASE" | cryptsetup luksOpen /dev/loop1 pup_crypt
   #get_password | cryptsetup luksOpen /dev/loop1 pup_crypt
   #while test $? -ne 0; do
   #cryptsetup -y luksOpen /dev/loop1 pup_crypt;
   #done
   mount -t ext3 -o noatime,rw /dev/mapper/pup_crypt $EFSMNT;check_status $?
   if [ "$?" = "0" ] ; then
   break
   else 
   losetup -d /dev/loop1
   echo "Can't mount file, Try password again." >/dev/console
   fi
   done
 else
Reference Links:

http://feraga.com/node/51
http://www.g-loaded.eu/2005/11/10/encry ... -and-luks/
http://www.redhat.com/archives/fedora-s ... 00056.html
http://ubuntuforums.org/showthread.php?t=199824&page=3
http://www.shimari.com/dm-crypt-on-raid/#why_dmcrypt
http://www.shimari.com/dm-crypt-on-raid/encrypted_home
http://www.saout.de/tikiwiki/tiki-index.php?page=HOWTO
http://www.ubuntuforums.org/showthread.php?t=120091
http://www.google.com/search?q=initrd+cryptsetup
Attachments
UnMountDrive.tar.gz
Script to UnMount Encrypted PupSave (leaves drive mounted).
(193 Bytes) Downloaded 720 times
MountDrive.tar.gz
Script To Mount Encrypted PupSave
(1019 Bytes) Downloaded 761 times
crypt-pupsave-LUKS.tar.gz
Script to Encrypt Pup_Save File with LUKS
(3.96 KiB) Downloaded 710 times
Luks-Modules.tar.gz
DM-MOD and DM-CRYPT Kernel Modules with Temporary Install Script for Puppy 2.12
(33.56 KiB) Downloaded 757 times
Last edited by John Doe on Tue 19 Dec 2006, 20:45, edited 6 times in total.

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#46 Post by 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 8)
Attachments
untitled2 (Small).gif
(48.48 KiB) Downloaded 1078 times

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#47 Post by 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. :oops:

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
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#48 Post by John Doe »

PaulBx1 wrote:Then I realized I had a bug in there. :oops:
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. ;-)
PaulBx1 wrote: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).
PaulBx1 wrote: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.
PaulBx1 wrote: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.
PaulBx1 wrote: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
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#49 Post by PaulBx1 »

Ah, politics. Always the most important thing. :lol: 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. :lol:

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#50 Post by 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?
Attachments
Error.jpg
(110.7 KiB) Downloaded 997 times

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#51 Post by 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". :roll: Still, probably worth trying ext2 to see if you have any more luck.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#52 Post by 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
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#53 Post by John Doe »

PaulBx1 wrote:What permissions do you have on the pup_save?
It's on a fat16 usb flash stick. No ACL of any kind.
PaulBx1 wrote: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.
PaulBx1 wrote: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.
PaulBx1 wrote: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.
PaulBx1 wrote: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
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#54 Post by John Doe »

PaulBx1 wrote:...probably nothing you don't already know about
Don't worry, I feel as lost as you said you were.
PaulBx1 wrote:...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.
PaulBx1 wrote:Password processing is new-line sensitive, meaning the reading will stop after encountering \n.
PaulBx1 wrote:password can not be read from...stream...that does not terminate
Looks like I should stop typing -n in there.
PaulBx1 wrote:...I suppose you know that, in your comment about piping it properly.
I did get it to work with a script using a pipe.
PaulBx1 wrote: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. :-)
PaulBx1 wrote: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
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#55 Post by 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.
Last edited by PaulBx1 on Fri 22 Dec 2006, 04:32, edited 1 time in total.

User avatar
Gn2
Posts: 943
Joined: Mon 16 Oct 2006, 05:33
Location: virtual - Veni vidi, nihil est adpulerit

#56 Post by 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
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#57 Post by 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
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#58 Post by 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

User avatar
Gn2
Posts: 943
Joined: Mon 16 Oct 2006, 05:33
Location: virtual - Veni vidi, nihil est adpulerit

#59 Post by 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
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#60 Post by 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. :shock: 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...
Last edited by PaulBx1 on Fri 22 Dec 2006, 05:00, edited 2 times in total.

Post Reply