Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 28 Nov 2014, 00:25
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Encrypted pup_save for Puppy 212
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 4 of 5 [73 Posts]   Goto page: Previous 1, 2, 3, 4, 5 Next
Author Message
John Doe

Joined: 01 Aug 2005
Posts: 1689
Location: Michigan, US

PostPosted: Sun 17 Dec 2006, 20:13    Post subject:  

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 Cool
untitled2 (Small).gif
 Description   
 Filesize   48.48 KB
 Viewed   882 Time(s)

untitled2 (Small).gif

Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Mon 18 Dec 2006, 15:12    Post subject:  

Well, that's something! Smile

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. Embarassed

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?
Back to top
View user's profile Send private message 
John Doe

Joined: 01 Aug 2005
Posts: 1689
Location: Michigan, US

PostPosted: Tue 19 Dec 2006, 04:09    Post subject:  

PaulBx1 wrote:
Then I realized I had a bug in there. Embarassed


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. Wink

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.
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Tue 19 Dec 2006, 12:08    Post subject:  

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

Quote:
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! Smile 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. Laughing
Back to top
View user's profile Send private message 
John Doe

Joined: 01 Aug 2005
Posts: 1689
Location: Michigan, US

PostPosted: Wed 20 Dec 2006, 04:54    Post subject:  

@Paul thoughtful reply tomorrow.

@Everyone, this is where I'm stuck.

Using the code and method here:
http://www.murga-linux.com/puppy/viewtopic.php?p=84588#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?
Error.jpg
 Description   
 Filesize   110.7 KB
 Viewed   811 Time(s)

Error.jpg

Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Wed 20 Dec 2006, 22:51    Post subject:  

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". Rolling Eyes Still, probably worth trying ext2 to see if you have any more luck.
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Wed 20 Dec 2006, 23:48    Post subject:  

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:
# 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.php?page=luksopen


Another note about password processing:
Quote:
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:
Quote:

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

However:
Quote:

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
Back to top
View user's profile Send private message 
John Doe

Joined: 01 Aug 2005
Posts: 1689
Location: Michigan, US

PostPosted: Thu 21 Dec 2006, 04:43    Post subject:  

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.
Back to top
View user's profile Send private message 
John Doe

Joined: 01 Aug 2005
Posts: 1689
Location: Michigan, US

PostPosted: Thu 21 Dec 2006, 05:43    Post subject:  

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. Smile

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
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Thu 21 Dec 2006, 11:33    Post subject:  

Quote:
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...

Quote:
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? Smile 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, 00:32; edited 1 time in total
Back to top
View user's profile Send private message 
Gn2


Joined: 16 Oct 2006
Posts: 936
Location: virtual - Veni vidi, nihil est adpulerit

PostPosted: Thu 21 Dec 2006, 14:19    Post subject:  

Quote:
So does Puppy use the bourne shell or not?

Code:
env
bash -v

Puppy sets profile - see your home variable - It also uses
BusyBox <> ASH
NOT the full shell CLI environment.
Quote:
Could we call a bash script during
Advanced Bash Scripting Guide
Code:
Chapter
34.1
Quote:
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 -
Quote:
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
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Thu 21 Dec 2006, 15:49    Post subject:  

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:
Quote:
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.
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Thu 21 Dec 2006, 16:38    Post subject:  

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
Back to top
View user's profile Send private message 
Gn2


Joined: 16 Oct 2006
Posts: 936
Location: virtual - Veni vidi, nihil est adpulerit

PostPosted: Thu 21 Dec 2006, 16:40    Post subject:  

Quote:
missing something;

Code:
PHYSICAL  ACCESS


If above is possible > ALL other security precautions are a waste of effort
Quote:
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 ?
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Thu 21 Dec 2006, 17:04    Post subject:  

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. Shocked 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, 01:00; edited 2 times in total
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 4 of 5 [73 Posts]   Goto page: Previous 1, 2, 3, 4, 5 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.2011s ][ Queries: 12 (0.0628s) ][ GZIP on ]