[opensuse-security] Weird encrypted filesystem problem.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have bumped into a weird problem with encrypted filesystems. It appears there are two incompatible types that use the same options in the cryptotab file. It's difficult to explain. I have replaced an old disk wit a bigger one. The old one had an encrypted partition predating SuSE 9.2. Over the time, I have created other partitions and copied files to encrypted filesystems in DVD, and never had problems. However, I discovered, after switching to the new disk, that although I could load the new encrypted partition, I was unable to load any of the old ones. In order to mount any of those encrypted filesystems, first I have to mount the obsolete (pre 9.2) one, then the rest - except that in that case, I'm unable to mount the new one. For example. I boot, and the "/etc/init.d/boot.crypto" script mounts the main encrypted partition fine. I then manually try to mount one of the auxiliaries: nimrodel:~/cripta.problem # losetup -a /dev/loop0: [000d]:2484 (/dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15) encryption=CryptoAPI/twofish-cbc nimrodel:~/cripta.problem # mount /mnt/crypta.x/ Password: mount: /dev/loop1: can't read superblock However, if edit the /etc/cryptotab to mount the obsolete one (I had to copy it over from the old disk for this purpose): /dev/loop1 /Grande/oldcriptadevicefile /A60/cripta xfs twofishSL92 noatime and now, I mount it: nimrodel:~/cripta.problem # /etc/init.d/boot.crypto start Activating crypto devices using /etc/cryptotab ... Please enter passphrase for /Grande/oldcriptadevicefile: Switching to SuSE 9.2 loop_fish2 compatibility mode. Please enter passphrase for /Grande/oldcriptadevicefile: fsck 1.38 (30-Jun-2005) /sbin/fsck.xfs: XFS file system. See the notice about 9.2 compatibility mode? Once this mode is activated, I can mount any of the partitions or backups I created during last year: (fstab) /biggy/crypta.bck_f.x0 /mnt/crypta.x xfs noauto,loop,encryption=twofish256 0 0 nimrodel:~/cripta.problem # mount /mnt/crypta.x/ Password: nimrodel:~/cripta.problem # mount /mnt/dvd.crypta.x/ Password: nimrodel:~/cripta.problem # mount | grep encryption /dev/hda15 on /cripta type xfs (rw,noatime,loop=/dev/loop0,encryption=twofish256) /Grande/oldcriptadevicefile on /A60/cripta type xfs (rw,noatime,loop=/dev/loop1,encryption=twofishSL92) /biggy/crypta.bck_f.x0 on /mnt/crypta.x type xfs (rw,loop=/dev/loop2,encryption=twofish256) /dev/hdc on /mnt/dvd.crypta.x type xfs (ro,noexec,nosuid,nodev,loop=/dev/loop3,encryption=twofish256) nimrodel:~/cripta.problem # losetup -a /dev/loop0: [000d]:2484 (/dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15) encryption=CryptoAPI/twofish-cbc /dev/loop1: [0314]:177 (/Grande/oldcriptadevicefile) encryption=twofish256 /dev/loop2: [1650]:135 (/biggy/crypta.bck_f.x0) encryption=twofish256 /dev/loop3: [000d]:5490 (/dev/dvd) encryption=twofish256 See? everything is mounted, old, medium, new (remember that "loop1" is in 9.2 compatibility mode, explicitly). The thing is, I first have to mount the new partition, using "encryption=twofish256". Second thing, I have to mount the old one, using "encryption=twofishSL92", which switches something in the system to "SuSE 9.2 loop_fish2 compatibility mode". Finally, I can mount the new partitions using "encryption=twofish256" as well, but which were created while there was already a mounted partition in 9.2 mode (during last year). That is, it seems that if twofishSL92 is active, new partitions in twofish256 need the old mode to be active to be able to mount! If not, they give errors: Filesystem "loop1": Disabling barriers, not supported by the underlying device XFS mounting filesystem loop1 XFS: Log inconsistent (didn't find previous header) XFS: failed to find log head XFS: log mount/recovery failed: error 5 XFS: log mount failed Feb 11 01:04:58 nimrodel kernel: XFS: Log inconsistent (didn't find previous header) Feb 11 01:04:58 nimrodel kernel: XFS: failed to find log head Feb 11 01:04:58 nimrodel kernel: XFS: log mount/recovery failed: error 5 Feb 11 01:04:58 nimrodel kernel: XFS: log mount failed My problem is now that I have to keep using the old compatibility mode! I have to keep this in the cryptotab file, and in that precise order: /dev/loop0 /dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15 /cripta xfs twofish256 noatime /dev/loop1 /Grande/oldcriptadevicefile /A60/cripta xfs twofishSL92 noatime And I will have to keep for ever that twofishSL92 file I do not want, simply in order to activate the old compatibility mode so that I can mount my backup dvds which do not use twofishSL92 but twofish256, but still need twofishSL92! Or, can I change some definition in the cryptotab file so that I can mount "twofish256" filesystems that require "twofishSL92" to be previously activated? - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFzmwLtTMYHG2NR9URAk9uAJ0f15fnbFkuPOoUAtUWlhMwiVJrywCfbOId jeUDB7zXgVOWM3pkJGUo2UQ= =ZKI4 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2007-02-11 at 02:06 +0100, I wrote:
I have bumped into a weird problem with encrypted filesystems.
It appears there are two incompatible types that use the same options in the cryptotab file.
It's difficult to explain.
Let me explain in another way: Encrypted filesystems using 'twofish256', created after mounting another filesystem that uses 'twofishSL92', are in fact created using 'twofishSL92' as well, silently. Thus, the keyword 'twofish256' refers in fact to two different and incompatible encryptions: to the real or new 'twofish256' (reported by losetup as 'CryptoAPI/twofish-cbc'), and to the old 'twofishSL92' (reported by losetup as 'twofish256'). The proof of this is that I can happily mount my 'twofish256' filesystems as 'twofishSL92' instead. Now, the first question is: is there another token I can use instead of 'twofish256' that is unique and refers to the real 'twofish256', that is, to 'CryptoAPI/twofish-cbc'? And the other question (to SuSE developers) is, how long will the 'twofishSL92' be maintained? (I have dozens of dvd backups made using 'twofish256' that are in fact 'twofishSL92') - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFzviStTMYHG2NR9URAsB4AJ4iW7+ILw/cX8deULn2EGPa12VjgwCcCHB2 Sa/wUgWJAsAsyakkbm3a74E= =aBQP -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Carlos E. R. wrote:
The Sunday 2007-02-11 at 02:06 +0100, I wrote:
I have bumped into a weird problem with encrypted filesystems.
It appears there are two incompatible types that use the same options in the cryptotab file.
It's difficult to explain.
Let me explain in another way:
Encrypted filesystems using 'twofish256', created after mounting another filesystem that uses 'twofishSL92', are in fact created using 'twofishSL92' as well, silently.
Thus, the keyword 'twofish256' refers in fact to two different and incompatible encryptions: to the real or new 'twofish256' (reported by losetup as 'CryptoAPI/twofish-cbc'), and to the old 'twofishSL92' (reported by losetup as 'twofish256').
Yes, unfortunately there are two incompatible on-disk formats for a twofish256 encrytion: http://en.opensuse.org/SDB:Crypto_Partition/Files_Changes_in_SUSE_Linux_Prof...
The proof of this is that I can happily mount my 'twofish256' filesystems as 'twofishSL92' instead.
Be careful. Writing to a partition that got mounted with the wrong encryption type may result in irreparable file system corruption.
Now, the first question is: is there another token I can use instead of 'twofish256' that is unique and refers to the real 'twofish256', that is, to 'CryptoAPI/twofish-cbc'?
No. As soon as you load loop_fish2 the twofishSL92 format gets used. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2007-02-11 at 12:51 +0100, Ludwig Nussel wrote:
Let me explain in another way:
Encrypted filesystems using 'twofish256', created after mounting another filesystem that uses 'twofishSL92', are in fact created using 'twofishSL92' as well, silently.
Thus, the keyword 'twofish256' refers in fact to two different and incompatible encryptions: to the real or new 'twofish256' (reported by losetup as 'CryptoAPI/twofish-cbc'), and to the old 'twofishSL92' (reported by losetup as 'twofish256').
Yes, unfortunately there are two incompatible on-disk formats for a twofish256 encrytion: http://en.opensuse.org/SDB:Crypto_Partition/Files_Changes_in_SUSE_Linux_Prof...
Yes, I remember reading that back in 9.3 time.
The proof of this is that I can happily mount my 'twofish256' filesystems as 'twofishSL92' instead.
Be careful. Writing to a partition that got mounted with the wrong encryption type may result in irreparable file system corruption.
If I try to mount with twofish256 right after booting, they don't mount, they fail. It is only after I mount the only explicit twofishSL92 filesystem that the rest can be mounted.
Now, the first question is: is there another token I can use instead of 'twofish256' that is unique and refers to the real 'twofish256', that is, to 'CryptoAPI/twofish-cbc'?
No. As soon as you load loop_fish2 the twofishSL92 format gets used.
Very unfortunate. The thing is that I have a three encrypted filesystems, plus dozens of dvds, some of them created using yast, and which I thought all of them were using the new system. But, as the old partition (twofishSL92) was mounted at creation time, all of them are in fact using twofishSL92 although I specified twofish256. I can't posibly read and reburn all those dvds! The problem is that Yast, or the kernel, or whatever, has created those filesystems using loop_fish2 without warning that it was using the old method. nimrodel:~ # losetup -a /dev/loop0: [000d]:2484 (/dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15) encryption=CryptoAPI/twofish-cbc /dev/loop1: [0314]:177 (/Grande/oldcriptadevicefile) encryption=twofish256 /dev/loop2: [1650]:135 (/biggy/crypta.bck_f.x0) encryption=twofish256 /dev/loop3: [0346]:11 (/Disco40/crypta.xfs.f) encryption=twofish256 /dev/loop4: [0703]:131 (/mnt/crypta.x9.dvdbck/zisofs.iso) /dev/loop5: [034c]:215 (/test_b/crypta.bck_f.x) encryption=twofish256 nimrodel:~ # lsmod | grep "fish\|crypt\|loop" loop_fish2 12928 4 twofish 43008 1 cryptoloop 3328 1 loop 15112 14 loop_fish2,cryptoloop Above, loop0 is using twofish and cryptoloop. loop1 is a dd backup of the old filesystem, predating suse 9.3, using loop_fish2 (both 1 and 0 contain the same data yet). The rest were created later, suposedly using the new twofish256, but they are using loop_fish2 instead. I can, I suposse, recreate the filesystems on disk to the new format. But the dvd backups are a different history! - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFz3s2tTMYHG2NR9URAhb/AJwKy+mHfe8+Yq99+eX2fYFV+DVtiwCdE/NT Xl2uK2BtJGRjxi7GtB+LNbc= =YgNb -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Carlos E. R. wrote:
The Sunday 2007-02-11 at 12:51 +0100, Ludwig Nussel wrote:
No. As soon as you load loop_fish2 the twofishSL92 format gets used.
Very unfortunate.
The thing is that I have a three encrypted filesystems, plus dozens of dvds, some of them created using yast, and which I thought all of them were using the new system. But, as the old partition (twofishSL92) was mounted at creation time, all of them are in fact using twofishSL92 although I specified twofish256.
I can't posibly read and reburn all those dvds!
The problem is that Yast, or the kernel, or whatever, has created those filesystems using loop_fish2 without warning that it was using the old method.
Yeah, that's an unfortunate situation indeed. I had a look at dm-crypt yesterday. Looks like a trivial patch is sufficient for it to be able to to access legacy images without the nasty side effects of loop_fish2. In case you don't mind breaking your whole system with barely tested software ;-) I've put the patch for dm-crypt.c and shell scripts that pass the correct parameters to cryptsetup here: http://www.suse.de/~lnussel/cryptsetup-legacy.tar.gz You need to install util-linux-crypto and if you want to recompile the kernel module also kernel-source. For example to mount a dvd: cryptsetup-twofishSL92 foo /dev/hdc mount /dev/mapper/foo /a Or an image: losetup /dev/loop0 img cryptsetup-twofish256 bar /dev/loop0 mount /dev/mapper/bar /b Note that this is experimental. I'd try it with read only dvd images first. No warranty that it works without breaking stuff. I'd be glad if someone could confirm that the method works without corrupting filesystems indeed though (also for pre-9.2 images). Hopefully we can get rid of loop_fish2 then. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-02-14 at 11:40 +0100, Ludwig Nussel wrote:
Carlos E. R. wrote:
The Sunday 2007-02-11 at 12:51 +0100, Ludwig Nussel wrote:
No. As soon as you load loop_fish2 the twofishSL92 format gets used.
Very unfortunate.
The thing is that I have a three encrypted filesystems, plus dozens of dvds, some of them created using yast, and which I thought all of them were using the new system. But, as the old partition (twofishSL92) was mounted at creation time, all of them are in fact using twofishSL92 although I specified twofish256.
I can't posibly read and reburn all those dvds!
The problem is that Yast, or the kernel, or whatever, has created those filesystems using loop_fish2 without warning that it was using the old method.
Yeah, that's an unfortunate situation indeed.
I have been very busy because I had a bad system crash; I blame the IDE cable (that flat ribbon one with 80 wires) that became faulty with so many unplugging and replugging while I was trying to install a new disk and solve the crypto problem and others... first my whole home partition (xfs) in one disk became wholly trashed (even the "label" disappeared). I even provoked a bug in xfs_repair that I should report - if I can recover the bug data! When I had that partition almost recovered, then down went the whole same disk! This time "/" (ext3) was almost unrecoverable (certainly unbootable after recovery) and the rest needed extensive fsck. And all this because I wanted to install a new disk to do a backup... I'm now using 10.2, upgraded from my 9.3 previous full backup. Easier for me than a fresh install, or because I just wanted to keep the chain of upgrades since 8.1 O:-) So I didn't see your message.
I had a look at dm-crypt yesterday. Looks like a trivial patch is sufficient for it to be able to to access legacy images without the nasty side effects of loop_fish2.
In case you don't mind breaking your whole system with barely tested software ;-) I've put the patch for dm-crypt.c and shell scripts that pass the correct parameters to cryptsetup here: http://www.suse.de/~lnussel/cryptsetup-legacy.tar.gz
I'm certainly interested, but... as you know I hosed my system last week, I am somewhat reluctant to expose it - so, how bad is that "breaking danger" you mention? :-?
You need to install util-linux-crypto and if you want to recompile the kernel module also kernel-source.
For example to mount a dvd: cryptsetup-twofishSL92 foo /dev/hdc mount /dev/mapper/foo /a
Or an image: losetup /dev/loop0 img cryptsetup-twofish256 bar /dev/loop0 mount /dev/mapper/bar /b
Note that this is experimental. I'd try it with read only dvd images first. No warranty that it works without breaking stuff. I'd be glad if someone could confirm that the method works without corrupting filesystems indeed though (also for pre-9.2 images). Hopefully we can get rid of loop_fish2 then.
Ok, but I suppose you mean read only for the crypto filesystem, not the system itself? My system is not encrypted, would that be endangered if I was testing to read encrypted dvds? You understand I'm "touchy" right now about such "dangers", don't you? ;-) At the moment, I have changed my crypto filesystems on the hard disk to the new system. It is only the DVDs that remain using the old loop_fish2, of course. If you think my normal filesystem would be safe (it is not encrypted), then I'm game. Or I could use another 10.2 system in the same computer, on a different partition: it wouldn't matter much it that one got corrupted, as long as there is no danger of propagating the damage to the rest of unmounted partitions. Am I too paranoic? ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF2P12tTMYHG2NR9URAsMlAJ9HyEelPD6ts+lNkBGg8Sf54WvzYQCglCMG fvy3Z+XHzNe7ApD/JFXwkb8= =2TY7 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Carlos E. R. wrote:
Note that this is experimental. I'd try it with read only dvd images first. No warranty that it works without breaking stuff. I'd be glad if someone could confirm that the method works without corrupting filesystems indeed though (also for pre-9.2 images). Hopefully we can get rid of loop_fish2 then.
Ok, but I suppose you mean read only for the crypto filesystem, not the system itself? My system is not encrypted, would that be endangered if I was testing to read encrypted dvds?
Unlikely. The patch for dm-crypt is small and only affects loop_fish2 compatibility. The comment about sector size dependency on the dm-crypt page made me a bit cautious. Meanwhile I talked to the author and we're confident that it's not an issue. You obviously cannot corrupt a filesystem on DVD as DVD's are usually inherently read only :-)
At the moment, I have changed my crypto filesystems on the hard disk to the new system. It is only the DVDs that remain using the old loop_fish2, of course. If you think my normal filesystem would be safe (it is not encrypted), then I'm game.
Not encrypted partitions are safe.
Am I too paranoic? ;-)
Maybe, but then welcome to the club ;-) You can never be too paranoid about this stuff. Esp the fine difference between loop_fish2's twofish 256 and cryptoapi's twofish 256 can severely damage the file system if you mount or fsck it with the wrong module. You're playing with fire if you use both loop_fish2 and cryptoapi's twofish256 in parallel. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-02-14 at 11:40 +0100, Ludwig Nussel wrote:
Yeah, that's an unfortunate situation indeed.
I had a look at dm-crypt yesterday. Looks like a trivial patch is sufficient for it to be able to to access legacy images without the nasty side effects of loop_fish2.
In case you don't mind breaking your whole system with barely tested software ;-) I've put the patch for dm-crypt.c and shell scripts that pass the correct parameters to cryptsetup here: http://www.suse.de/~lnussel/cryptsetup-legacy.tar.gz
You need to install util-linux-crypto and if you want to recompile the kernel module also kernel-source.
For example to mount a dvd: cryptsetup-twofishSL92 foo /dev/hdc mount /dev/mapper/foo /a
Or an image: losetup /dev/loop0 img cryptsetup-twofish256 bar /dev/loop0 mount /dev/mapper/bar /b
I'm finally trying this up, but I can't make it go. I compiled cryptsetup-legacy.tar.gz using the script "compile.sh". I have kernel-source installed (I'm running my own compiled kernel). nimrodel:~/bin/cryptsetup-legacy # ./compile.sh patching file dm-crypt.c make: Entering directory `/usr/src/linux-2.6.18.8-0.1-obj/i386/default' make -C ../../../linux-2.6.18.8-0.1 O=../linux-2.6.18.8-0.1-obj/i386/default modules CC [M] /root/bin/cryptsetup-legacy/dm-crypt.o Building modules, stage 2. MODPOST CC /root/bin/cryptsetup-legacy/dm-crypt.mod.o LD [M] /root/bin/cryptsetup-legacy/dm-crypt.ko make: Leaving directory `/usr/src/linux-2.6.18.8-0.1-obj/i386/default' ok, now run insmod ./dm-crypt.ko But: nimrodel:~/bin/cryptsetup-legacy # insmod ./dm-crypt.ko insmod: error inserting './dm-crypt.ko': -1 Invalid module format The kernel log shows: Apr 16 00:19:05 nimrodel kernel: dm_crypt: disagrees about version of symbol struct_module My guess is that it doesn't work because I'm not using kernel-default, but my compiled version. How should I modify the compile script? Perhaps I should add my own directory to "/usr/src/linux-obj/i386/" (I don't know how), or copy the modified dm-crypt.c to /usr/src/linux/drivers/md/ and recompile the whole module tree? The last one probably needs rebooting. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGIrhltTMYHG2NR9URAnTHAJ9mC9jVAMwrbSh2r71okl1wlOUDOgCeIv8E 5any9kGbc0CXE1bERmUtrDo= =FoSC -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Carlos E. R. wrote:
I'm finally trying this up, but I can't make it go. I compiled cryptsetup-legacy.tar.gz using the script "compile.sh". I have kernel-source installed (I'm running my own compiled kernel). [...] Perhaps I should add my own directory to "/usr/src/linux-obj/i386/" (I don't know how), or copy the modified dm-crypt.c to /usr/src/linux/drivers/md/ and recompile the whole module tree? The last one probably needs rebooting.
In this case modify the script to use the directoy where your kernel sources are. Alternatively patch your kernel sources directly. Or just try a 10.3 Alpha version, the dm-crypt patch is included there already. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-04-16 at 09:27 +0200, Ludwig Nussel wrote:
In this case modify the script to use the directoy where your kernel sources are. Alternatively patch your kernel sources directly. Or just try a 10.3 Alpha version, the dm-crypt patch is included there already.
10.3 I can't even try because I have 20 partitions in hda, and 16 in hdd: I understand that the maximum is 15 for the moment. I have modified 'compile.sh' as follows: #!/bin/sh set -e cp /usr/src/linux/drivers/md/dm{.h,-crypt.c} . patch -p3 < dm-crypt-nulliv.diff #make -C /usr/src/linux-obj/i386/default M=$(pwd) modules make -C /usr/src/linux M=$(pwd) modules rm -rf .tmp_versions Module.symvers .*.cmd *.o *.mod.* echo "ok, now run insmod ./dm-crypt.ko" but insmod fails: nimrodel:~/bin/cryptsetup-legacy # insmod ./dm-crypt.ko insmod: error inserting './dm-crypt.ko': -1 File exists I guess that is because the normal crypto partition is active, but I don't know; 'lsmod' says: Module Size Used by dm_crypt 12552 0 dm_mod 62264 1 dm_crypt cryptoloop 3968 2 loop 18184 5 cryptoloop So the alternative is to compile all modules and reboot. [...] Done that, but now it fails somewhere else: nimrodel:~/bin/cryptsetup-legacy # ./cryptsetup-twofishSL92 foo /dev/hdc Enter passphrase: nimrodel:~/bin/cryptsetup-legacy # l /dev/mapper/ total 0 drwxr-xr-x 2 root root 80 Apr 16 23:41 ./ drwxr-xr-x 11 root root 8200 Apr 16 23:41 ../ lrwxrwxrwx 1 root root 16 Apr 16 23:32 control -> ../device-mapper brw------- 1 root root 253, 0 Apr 16 23:41 foo nimrodel:~/bin/cryptsetup-legacy # mount /dev/mapper/foo a/ mount: Function not implemented I have no idea what function it is talking about... but as far as I know,, I'm following your instructions. I forgot to 'insmod dm-crypt', but it is there already: nimrodel:~/bin/cryptsetup-legacy # lsmod | grep dm_crypt dm_crypt 12808 1 dm_mod 62264 2 dm_crypt I noticed that the compile.sh aplies dm-crypt-nulliv.diff, but there is another file, 'cryptsetup-luks-1.0.4-loop_fish2_compat.diff' that is not applied anywhere. Should I? If so, what to and how? Also, I have that 'foo' mapped, but I don't know how to unmap it. Can I simply eject the dvd in /dev/hdc? This is new to me. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGI/cvtTMYHG2NR9URAu0NAJwKJqOP6P7IrQkkcjayeAqP+aA+AACeJ49o 7kr2VgYjJQu4dp+xelomXLw= =D0iw -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Carlos E. R. wrote:
So the alternative is to compile all modules and reboot.
[...]
Done that, but now it fails somewhere else:
nimrodel:~/bin/cryptsetup-legacy # ./cryptsetup-twofishSL92 foo /dev/hdc Enter passphrase: nimrodel:~/bin/cryptsetup-legacy # l /dev/mapper/ total 0 drwxr-xr-x 2 root root 80 Apr 16 23:41 ./ drwxr-xr-x 11 root root 8200 Apr 16 23:41 ../ lrwxrwxrwx 1 root root 16 Apr 16 23:32 control -> ../device-mapper brw------- 1 root root 253, 0 Apr 16 23:41 foo
Looks good
nimrodel:~/bin/cryptsetup-legacy # mount /dev/mapper/foo a/ mount: Function not implemented
I have no idea what function it is talking about... but as far as I know,, I'm following your instructions.
Hmm, no idea. Are you sure a/ is a directory? Any suspicious entry in /var/log/messages? Are you sure the device is not used by cryptoloop already?
I noticed that the compile.sh aplies dm-crypt-nulliv.diff, but there is another file, 'cryptsetup-luks-1.0.4-loop_fish2_compat.diff' that is not applied anywhere. Should I? If so, what to and how?
That's a patch for cryptsetup. You only need it if you use the even older 160bit twofish encryption.
Also, I have that 'foo' mapped, but I don't know how to unmap it. Can I simply eject the dvd in /dev/hdc? This is new to me.
dmsetup remove foo cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-04-17 at 09:47 +0200, Ludwig Nussel wrote:
Looks good
nimrodel:~/bin/cryptsetup-legacy # mount /dev/mapper/foo a/ mount: Function not implemented
I have no idea what function it is talking about... but as far as I know,, I'm following your instructions.
Hmm, no idea. Are you sure a/ is a directory? Any suspicious entry in /var/log/messages? Are you sure the device is not used by cryptoloop already?
Yes, a/ is a directory I made for the purpose as a second try. hdc can't be in use, as it is encrypted via the old method that doesn't work once there is another crypto partition/file active with the new method. Entries in log... not a single message in the kernel log, that one I looked. In messages I don't remember... I have to try again, I don't remember the exact time I tried, to look it up in the logs. nimrodel:~ # lsmod | grep dm_crypt nimrodel:~ # modprobe dm_crypt nimrodel:~ # lsmod | grep dm_crypt dm_crypt 12808 0 dm_mod 62264 1 dm_crypt nimrodel:~ # mkdir foodir I put the dvd in the drive at this moment, and gnome tries to automount, failing, of course: Apr 17 12:36:38 nimrodel kernel: FAT: invalid media value (0xde) Apr 17 12:36:38 nimrodel kernel: VFS: Can't find a valid FAT filesystem on dev hdc. Apr 17 12:36:38 nimrodel kernel: hfs: can't find a HFS filesystem on dev hdc. Apr 17 12:36:38 nimrodel kernel: MINIX-fs: blocksize too small for device Apr 17 12:36:38 nimrodel kernel: ReiserFS: hdc: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on hdc Apr 17 12:36:39 nimrodel kernel: Unable to identify CD-ROM format. Apr 17 12:36:39 nimrodel kernel: VFS: Can't find ext3 filesystem on dev hdc. Apr 17 12:36:39 nimrodel kernel: VFS: Can't find an ext2 filesystem on dev hdc. So: nimrodel:~ # cryptsetup-twofishSL92 foo /dev/hdc Enter passphrase: nimrodel:~ # The passphrase is accepted, and the dvd spins up. Nothing in kernel log, nothing in messages. nimrodel:~ # l /dev/mapper/ total 0 drwxr-xr-x 2 root root 80 Apr 17 12:38 ./ drwxr-xr-x 11 root root 8220 Apr 17 12:38 ../ lrwxrwxrwx 1 root root 16 Apr 17 02:07 control -> ../device-mapper brw------- 1 root root 253, 0 Apr 17 12:38 foo nimrodel:~ # mount /dev/mapper/foo foodir/ mount: Function not implemented <== takes some five seconds) nimrodel:~ # nimrodel:~ # dmsetup info foo Name: foo State: ACTIVE Tables present: LIVE Open count: 0 Event number: 0 Major, minor: 253, 0 Number of targets: 1 nimrodel:~ # dmsetup status foo 0 9179136 crypt Nothing at all in the logs (and I have "KERNEL_LOGLEVEL=1" in /etc/sysconfig/syslog). Is there something I can do to expand info? How to know what that "Function not implemented" is refering to? Could it be that the mount program in 10.2 can not mount device-mapper things? Perhaps I could try with a plain dvd, if you tell me a procedure. (I tried again with a intentionally wrong passphrase, and there is no complain; I don't like that). The corresponding line in fstab for that dvd is: /dev/dvd /mnt/dvd.crypta.x9 auto ro,noauto,user,loop,encryption=twofishSL92 The filesystem is XFS. I can mount it once I umount the new style crypt partitions, or freshly after reboot. After copying over my files, I disable the sl92 mode by doing: rmmod loop_fish2 cryptoloop twofish and then mount my new style partitions again. I did this yesterday, as I needed those files, and so I tested that the DVD was still ok. Today I tried with a different dvd.
I noticed that the compile.sh aplies dm-crypt-nulliv.diff, but there is another file, 'cryptsetup-luks-1.0.4-loop_fish2_compat.diff' that is not applied anywhere. Should I? If so, what to and how?
That's a patch for cryptsetup. You only need it if you use the even older 160bit twofish encryption.
Ah, ok. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGJK6TtTMYHG2NR9URAvTLAKCUqbOxsJYxgxstcjmcb9balRMkNwCfe4Tx Yzt84z8Hn3oFuG3IgdKXqrE= =2JHp -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Carlos E. R. wrote:
The Tuesday 2007-04-17 at 09:47 +0200, Ludwig Nussel wrote: Nothing at all in the logs (and I have "KERNEL_LOGLEVEL=1" in /etc/sysconfig/syslog).
Is there something I can do to expand info? How to know what that "Function not implemented" is refering to?
Maybe an strace of mount gives some insight.
Could it be that the mount program in 10.2 can not mount device-mapper things?
No, mount doesn't care where the device comes from.
Perhaps I could try with a plain dvd, if you tell me a procedure.
plain dvd? You mean using an unencrypted dvd via device mapper?
(I tried again with a intentionally wrong passphrase, and there is no complain; I don't like that).
There is no complaint at this point with the old method either. It's up to you/a script/mount to determine whether the decrypted data makes sense.
The corresponding line in fstab for that dvd is:
/dev/dvd /mnt/dvd.crypta.x9 auto ro,noauto,user,loop,encryption=twofishSL92
The filesystem is XFS.
Is the filesystem properly identified as xfs after you've set up the dm target? Ie does /lib/udev/vol_id /dev/mapper/foo tell you that it's xfs? cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-04-17 at 13:56 +0200, Ludwig Nussel wrote:
Is there something I can do to expand info? How to know what that "Function not implemented" is refering to?
Maybe an strace of mount gives some insight.
I'll try that later.
Could it be that the mount program in 10.2 can not mount device-mapper things?
No, mount doesn't care where the device comes from.
Ok.
Perhaps I could try with a plain dvd, if you tell me a procedure.
plain dvd? You mean using an unencrypted dvd via device mapper?
Right, to see if mount can mount such a device.
(I tried again with a intentionally wrong passphrase, and there is no complain; I don't like that).
There is no complaint at this point with the old method either. It's up to you/a script/mount to determine whether the decrypted data makes sense.
let me verify that... no, not so: nimrodel:/etc/postfix # umount /mnt/crypta.mm.x/ nimrodel:/etc/postfix # mount /mnt/crypta.mm.x/ Password: mount: wrong fs type, bad option, bad superblock on /dev/loop1, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so If I type the passphrase (actually, the same one that the dvd uses) with one letter missing, I get that error above. This one mounts with this line in fstab: /biggy/crypta_f.mm.x /mnt/crypta.mm.x xfs noauto,loop,encryption=twofish256 1 2 I think that if I mount manually, using losetup, the error message is a bit clearer.
The corresponding line in fstab for that dvd is:
/dev/dvd /mnt/dvd.crypta.x9 auto ro,noauto,user,loop,encryption=twofishSL92
The filesystem is XFS.
Is the filesystem properly identified as xfs after you've set up the dm target? Ie does /lib/udev/vol_id /dev/mapper/foo tell you that it's xfs?
Let me see: nimrodel:/etc/postfix # /lib/udev/vol_id /dev/mapper/foo ID_FS_USAGE=filesystem ID_FS_TYPE=xfs ID_FS_VERSION= ID_FS_UUID=3c3574ab-f3c4-4540-98cd-14c4d7125cc5 ID_FS_LABEL=crpt_dvd_xfs ID_FS_LABEL_SAFE=crpt_dvd_xfs nimrodel:/etc/postfix # Seems it is. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGJMRwtTMYHG2NR9URAl8NAKCIc6PYQFtSvW2cZAmEEMO+qrheTACfUONb 9H9gihxrB4Qk7IJKKzrNbw0= =VcF+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-04-17 at 13:56 +0200, Ludwig Nussel wrote:
Is there something I can do to expand info? How to know what that "Function not implemented" is refering to?
Maybe an strace of mount gives some insight.
It does indeed. I did: # strace -ff -o mountrace mount /dev/mapper/foo foodir/ and the 'mountrace' file contains: brk(0x8088000) = 0x8088000 close(3) = 0 stat64("/sbin/mount.xfs", 0xbf9ec6f0) = -1 ENOENT (No such file or directory) mount("/dev/mapper/foo", "foodir/", "xfs", MS_MGC_VAL, NULL) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0 write(2, "mount: Function not implemented\n", 32) = 32 exit_group(32) = ? Truly, '/sbin/mount.xfs' does not exist in my system. Either that, or the non existing function is 'mount()'. I case I'm jumping to conclussions too fast, I'll try to attach the file to this email, it's under 6KiB. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGJNc0tTMYHG2NR9URAjxVAKCY7bP3tK51x43XZFYyrgTJE848uQCeMLNN Qzq/J1z3MbsgSjEJuab9BCM= =kVrC -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Tuesday 2007-04-17 at 13:56 +0200, Ludwig Nussel wrote:
Is there something I can do to expand info? How to know what that "Function not implemented" is refering to?
Maybe an strace of mount gives some insight.
It does indeed. I did:
# strace -ff -o mountrace mount /dev/mapper/foo foodir/
and the 'mountrace' file contains:
brk(0x8088000) = 0x8088000 close(3) = 0 stat64("/sbin/mount.xfs", 0xbf9ec6f0) = -1 ENOENT (No such file or directory) mount("/dev/mapper/foo", "foodir/", "xfs", MS_MGC_VAL, NULL) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0 write(2, "mount: Function not implemented\n", 32) = 32 exit_group(32) = ?
Truly, '/sbin/mount.xfs' does not exist in my system. Either that, or the non existing function is 'mount()'.
The function does exist, it just throws an ENOSYS error :-) Do you have DVDs with file systems other than xfs? Do they work? cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-04-17 at 17:24 +0200, Ludwig Nussel wrote:
close(3) = 0 stat64("/sbin/mount.xfs", 0xbf9ec6f0) = -1 ENOENT (No such file or directory) mount("/dev/mapper/foo", "foodir/", "xfs", MS_MGC_VAL, NULL) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0 write(2, "mount: Function not implemented\n", 32) = 32 exit_group(32) = ?
Truly, '/sbin/mount.xfs' does not exist in my system. Either that, or the non existing function is 'mount()'.
The function does exist, it just throws an ENOSYS error :-)
Ah :-( ¿Is that a bug I should report in bugzilla? And the missing "/sbin/mount.xfs"? What is that?
Do you have DVDs with file systems other than xfs? Do they work?
I have plain non encripted dvds, iso...something. They certainly work via normal plain mount. And the encripted ones work well via the crypto compatibility thing, which you know means that I can't use newly created crypto filesystems that use a diferent module (twofish256 vs CryptoAPI/twofish-cbc), using plain mount. I also have a concoction of zisofs compressed and xfs encripted filesystems, but that one is complex to test (it worked last time I tried some months back). I have no idea how to mount plain dvds using the device map thing, which is totally new stuff to me. Do you know a howto somewhere? Man pages assume you already know what you are looking for, too terse and useless in this case. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGJRlhtTMYHG2NR9URAvjTAJ9XMaNczgQ8kCRO1NwyHc0FQj1k3gCcC1yF tolHnPn7CWkvg5w8g1ebXpg= =6lKu -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Tuesday 2007-04-17 at 17:24 +0200, Ludwig Nussel wrote:
close(3) = 0 stat64("/sbin/mount.xfs", 0xbf9ec6f0) = -1 ENOENT (No such file or directory) mount("/dev/mapper/foo", "foodir/", "xfs", MS_MGC_VAL, NULL) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0 write(2, "mount: Function not implemented\n", 32) = 32 exit_group(32) = ?
Truly, '/sbin/mount.xfs' does not exist in my system. Either that, or the non existing function is 'mount()'.
The function does exist, it just throws an ENOSYS error :-)
Ah :-(
¿Is that a bug I should report in bugzilla?
That's what I'm trying to find out.
And the missing "/sbin/mount.xfs"? What is that?
Normal, mount first checks if there is a special mount program for a filesystem.
I also have a concoction of zisofs compressed and xfs encripted filesystems, but that one is complex to test (it worked last time I tried some months back).
I don't understand what you mean. xfs is not an encryption algorithm it's a filesystem just as zisofs is.
I have no idea how to mount plain dvds using the device map thing, which
The device mapper is of no use there. You can just mount the device directly. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-04-18 at 11:30 +0200, Ludwig Nussel wrote:
The function does exist, it just throws an ENOSYS error :-)
Ah :-(
¿Is that a bug I should report in bugzilla?
That's what I'm trying to find out.
Ah, ok, then just tell me when you have something else I could test.
And the missing "/sbin/mount.xfs"? What is that?
Normal, mount first checks if there is a special mount program for a filesystem.
I see.
I also have a concoction of zisofs compressed and xfs encripted filesystems, but that one is complex to test (it worked last time I tried some months back).
I don't understand what you mean. xfs is not an encryption algorithm it's a filesystem just as zisofs is.
Ok. I'll explain. - First I generate a zisofs compressed dvd image, using mkzftree (1) and "mkisofs -Z", which I name "zisofs.iso". - Create an xfs image of an encrypted filesystem (losetup, twofish, etc), in file '/Disco40/crypta.xfs.f' - I mount the xfs image, and copy on the resulting filesystem the iso9660/zisofs dvd image created earlier (zisofs.iso). - I umount the xfs image, and burn it to a dvd. The resulting dvd is both compressed and encrypted, and I mount it thus; in /etc/fstab I have: /Disco40/crypta.xfs.f /mnt/crypta.x9.dvdbck xfs loop,noauto,user,encryption=twofishSL92 0 0 #¡Encadenado! /mnt/crypta.x9.dvdbck/zisofs.iso /mnt/crypta.x9z.dvdbck auto loop,ro,noauto,user,exec 0 0 The above are the lines for the dvd creation step. For reading the dvd back, I lost the entries, but they should be: /dev/dvd /mnt/dvd.crypta.x9 auto ro,noauto,user,loop,encryption=twofishSL92 0 0 /mnt/dvd.crypta.x9/zisofs.iso /mnt/dvd.crypta.x9z auto loop,ro,noauto,user,exec 0 0 First, I do "mount /mnt/crypta.x9.dvdbck", the encrypted xfs image. Next, I loop mount the compressed image on it, using "mount /mnt/crypta.x9z.dvdbck". Not too weird, I hope ;-) (I use twofishSL92 inadvertently, as explained at the start of the thread)
I have no idea how to mount plain dvds using the device map thing, which
The device mapper is of no use there. You can just mount the device directly.
I know. I just mean that perhaps it is possible to test that way if mount is capable of mounting a plain dvd via this remaper thing, or if it only fails when it is encrypted. But maybe that's not an issue, I really don't know. You are the expert, so whatever you say :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGJkcNtTMYHG2NR9URApdvAKCYSAUauI8o8cxjXS7wuMeiFr1CjACeI49S qoHR4o5LxZNSY0mbGmlLKKA= =NYod -----END PGP SIGNATURE-----
Carlos E. R. wrote:
I also have a concoction of zisofs compressed and xfs encripted filesystems, but that one is complex to test (it worked last time I tried some months back).
I don't understand what you mean. xfs is not an encryption algorithm it's a filesystem just as zisofs is.
Ok. I'll explain.
- First I generate a zisofs compressed dvd image, using mkzftree (1) and "mkisofs -Z", which I name "zisofs.iso". - Create an xfs image of an encrypted filesystem (losetup, twofish, etc), in file '/Disco40/crypta.xfs.f' - I mount the xfs image, and copy on the resulting filesystem the iso9660/zisofs dvd image created earlier (zisofs.iso). - I umount the xfs image, and burn it to a dvd.
What do you need the xfs image for? You can just burn the result of encrypting zisofs.iso. Anyways. Looks like xfs doesn't work with the sector size of a cdrom. It works if you attach a loop device first and then use the loop device for cryptsetup-twofishSL92. e.g. losetup /dev/loop0 /dev/hdc cryptsetup-twofishSL92 foo /dev/loop0 cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-04-20 at 15:14 +0200, Ludwig Nussel wrote:
- First I generate a zisofs compressed dvd image, using mkzftree (1) and "mkisofs -Z", which I name "zisofs.iso". - Create an xfs image of an encrypted filesystem (losetup, twofish, etc), in file '/Disco40/crypta.xfs.f' - I mount the xfs image, and copy on the resulting filesystem the iso9660/zisofs dvd image created earlier (zisofs.iso). - I umount the xfs image, and burn it to a dvd.
What do you need the xfs image for? You can just burn the result of encrypting zisofs.iso.
I don't know how to encrypt an iso image. The encryption procedure I know is: dd if=/dev/zero of=crypta.file bs=1M count=4482 losetup -T -e twofish256 /dev/loop1 crypta.file mkfs -L "EncriptedBackup" -t xfs /dev/loop1 mount -t xfs /dev/loop1 /mnt/tmp I don't know how i can adapt mkisofs so that it creates an encrypted image. You see, there are man pages on the encryption programs, but I haven't seen a howto on how to combine all of them.
Anyways. Looks like xfs doesn't work with the sector size of a cdrom. It works if you attach a loop device first and then use the loop device for cryptsetup-twofishSL92. e.g. losetup /dev/loop0 /dev/hdc cryptsetup-twofishSL92 foo /dev/loop0
You mean that the devmapping thing will not work? Because I can mount them ok without that (execept the SL92 compatibility problem, that is). Ah, I see! nimrodel:~ # losetup /dev/loop2 /dev/hdc nimrodel:~ # cryptsetup-twofishSL92 foo /dev/loop2 Enter passphrase: nimrodel:~ # mount /dev/mapper/foo foodir/ nimrodel:~ # l foodir/ total 4305612 ... It works! Wow, thanks! - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGKQjOtTMYHG2NR9URArmNAJ4w3aSZNprz4FZDmBBXxW8SRc+laQCfRNtv 1nPzGYQ/vuYy+HI52ShNQuU= =Y8qF -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Carlos E. R. wrote:
The Friday 2007-04-20 at 15:14 +0200, Ludwig Nussel wrote:
What do you need the xfs image for? You can just burn the result of encrypting zisofs.iso.
I don't know how to encrypt an iso image.
The encryption procedure I know is:
dd if=/dev/zero of=crypta.file bs=1M count=4482 losetup -T -e twofish256 /dev/loop1 crypta.file mkfs -L "EncriptedBackup" -t xfs /dev/loop1 mount -t xfs /dev/loop1 /mnt/tmp
I don't know how i can adapt mkisofs so that it creates an encrypted image.
# mkisofs -J -r -o img.iso stuff # cp img.iso img.iso.crypted # losetup /dev/loop0 img.iso.crypted # cryptsetup-twofish256 foo /dev/loop0 # cp img.iso /dev/mapper/foo # dmsetup remove foo # losetup -d /dev/loop0
Anyways. Looks like xfs doesn't work with the sector size of a cdrom. It works if you attach a loop device first and then use the loop device for cryptsetup-twofishSL92. e.g. losetup /dev/loop0 /dev/hdc cryptsetup-twofishSL92 foo /dev/loop0
You mean that the devmapping thing will not work? Because I can mount them ok without that (execept the SL92 compatibility problem, that is).
Ah, I see!
nimrodel:~ # losetup /dev/loop2 /dev/hdc nimrodel:~ # cryptsetup-twofishSL92 foo /dev/loop2 Enter passphrase: nimrodel:~ # mount /dev/mapper/foo foodir/ nimrodel:~ # l foodir/ total 4305612 ...
It works! Wow, thanks!
Good to hear. Thanks for testing! cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-04-24 at 10:17 +0200, Ludwig Nussel wrote:
I don't know how to encrypt an iso image.
The encryption procedure I know is:
dd if=/dev/zero of=crypta.file bs=1M count=4482 losetup -T -e twofish256 /dev/loop1 crypta.file mkfs -L "EncriptedBackup" -t xfs /dev/loop1 mount -t xfs /dev/loop1 /mnt/tmp
I don't know how i can adapt mkisofs so that it creates an encrypted image.
# mkisofs -J -r -o img.iso stuff # cp img.iso img.iso.crypted # losetup /dev/loop0 img.iso.crypted # cryptsetup-twofish256 foo /dev/loop0 # cp img.iso /dev/mapper/foo # dmsetup remove foo # losetup -d /dev/loop0
Ahhh... ahhh... clap! (mouth hanging open and being manually shut). (didn't notice that part of the answer, Pine shows the lines starting with "#" in blue the same as those with ">") I will have to try that procedure one day... But I have to say that my procedure is faster. Once I have created the initial XFS image, all I do is: - mount it on a loop (R/W) - copy over those files I want - umount - burn. - mount "normally" (modified fstab line) The image remains there for reuse many times, encrypted. The iso image has to be created each time taking care of the maximum size, and then needs a second encrypted image. In disk I have to keep one non encrypted iso image at least part of the time. Frankly, I seem to prefer XFS dvds to ISO dvds (encrypted or plain). I can "create" them with normal tools, moving or copying files, as the image is read/write and isos are not: size has to be calculated. The obvious snag is that they are not portable, but so what? ;-) The second non obvious snag is that the XFS image can not be mounted at the same time as the burned DVD: they have the same UUID. Unless there is another problem with them I'm unaware of, of course.
...
It works! Wow, thanks!
Good to hear. Thanks for testing!
Welcome! :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGOG7rtTMYHG2NR9URApJsAJ42y/m1jIfj0Obz5QSRnnIWeYU+/QCfQeWK 7g0ab8UVbjbqHTh3/pJGegY= =SM9m -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
participants (2)
-
Carlos E. R. -
Ludwig Nussel