From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 Description of problem: The patch distributed with the Linux kernel crypto patches (http://www.kernel.org/pub/linux/kernel/crypto/v2.4/) has not been applied to util-linux and losetup. This means Red Hat Linux does not support encrypted loopback filesystems out of the box. See http://www.linuxdoc.org/HOWTO/Loopback-Encrypted-Filesystem-HOWTO.html#toc4. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: losetup -e aes /dev/loop0 /etc/cryptfile Actual Results: Losetup told me that AES was not supported. Expected Results: Losetup should have prompted me for a keysize and password. Upon entering the password, the loop device should have been attached to a plaintext filesystem image. Additional info:
There may be export issues I don't know of... I'd rather just get this integrated upstream.
I talked to the upstream maintainer - he will probably integrate some sort of crypto patch into future releases. I'll pull it in at that time.
*** Bug 74776 has been marked as a duplicate of this bug. ***
*** Bug 78552 has been marked as a duplicate of this bug. ***
*** Bug 78544 has been marked as a duplicate of this bug. ***
*** Bug 78550 has been marked as a duplicate of this bug. ***
Upstream maintainer says this will be resolved in util-linux-2.12.
Please reconsider this decision. Recent Red Hat Linux kernels (2.4.18-17.* at least, perhaps even earlier ones) already have the CryptoAPI patch installed. I heavily doubt the Red Hat kernel package maintainers would've put the CryptoAPI patch in if there were export issues that Red Hat hasn't already taken care of. Waiting for util-linux-2.12 is a poor option, for the simple reason that strong cryptography is something that is useful (necessary, for many people) *now*, and there's no telling when util-linux-2.12 will be released. (I mean, for Pete's sake, this bug report was initially filed against Red Hat Linux *6.2*. There have been 5 (soon to be 6) Red Hat Linux releases since then, and there's still no CryptoAPI support in util-linux.) Another way to look at it: if util-linux-2.12 happens sooner rather than later, then that minimizes the number of Red Hat Linux releases for which Red Hat has to maintain the patch. If util-linux-2.12 happens later rather than sooner, then that still justifies Red Hat applying the CryptoAPI patch to 2.11, because otherwise Red Hat's customers would've have to wait too long to get a CryptoAPI-aware util-linux. While I'm (of course) not familiar with Red Hat's release schedule, I would hope that if you act quickly, you could apply the CryptoAPI patch to util-linux and get it included in the Phoebe test cycle, so that 8.1 (or whatever it's called) has CryptoAPI support out-of-the-box. Finally, there's even a handy-dandy patch to do exactly what is required: http://www.kernel.org/pub/linux/kernel/people/hvr/util-linux-cryptoapi/ (I've been using this patch since 8.0 came out, and I haven't yet encountered any problems with it.)
Go, man, go. Use the "handy-dandy patch to do exactly what is required", we know how easy patches are to add to SRPM's; dead easy. Do it, man, do it. http://www.kernel.org/pub/linux/kernel/people/hvr/util-linux-cryptoapi/ Ralston says's he USING that patch; that makes it a last-half-hour-before-lunch type of job. Sam
I just installed Phoebe version 2, and needed to get to my encrypted partitions, so I updated the CryptoAPI patch for util-linux-2.11y-2. The util-linux.spec file changes are easy: --- util-linux.spec.old 2003-01-14 12:32:33.000000000 -0500 +++ util-linux.spec 2003-01-22 01:54:34.000000000 -0500 @@ -10,7 +10,7 @@ Summary: A collection of basic system utilities. Name: util-linux Version: 2.11y -Release: 2 +Release: 2.int License: distributable Group: System Environment/Base @@ -87,6 +87,7 @@ #Patch200: util-linux-2.11w-hammer.patch Patch123: util-linux-2.11y-blkgetsize-81069.patch Patch124: util-linux-2.11y-umount-75421.patch +Patch125: util-linux-2.11y-cryptoapi.patch ########### END upstreamable Obsoletes: fdisk tunelp @@ -197,6 +198,7 @@ #patch200 -p1 -b .hammer %patch123 -p1 -b .blkgetsize %patch124 -p1 -b .umount +%patch125 -p1 -b .cryptoapi # All of this patch is in except a 'max swap size' change, which # doesn't seem to be needed @@ -545,6 +547,9 @@ /sbin/losetup %changelog +* Wed Jan 22 2003 James Ralston <ralston> 2.11y-2.int +- add the CryptoAPI patch + * Mon Jan 13 2003 Elliot Lee <sopwith> 2.11y-2 - Fix #81069, #75421 I'll attach the patch next. I've already made my case for this (see my 2003-01-20 00:24 comment), so I'll shut up now.
Created attachment 89508 [details] util-linux-2.11y-cryptoapi.patch
Confirming - the patch works just as expected without a problem. No compilation warnings nor errors as a result of the patch.
Well I applied to patches to util-linux-2.11r-10 on my rh8 system; (I had to adjust the patch slightly on account of all the other patches) but it seems to work fine; though only cipher-aes came with my kernel.
I just ran into the same problem. Shipping the kenrel stuff but not the correspondign user land tools makes absolutely no sense to me. Please patch util-linux. Thanks.
Since there is no util-linux-2.12 in sight, please reconside rhtis for the next release.
I'm still using James's patch for util-linux (losetup and mount) under Red Hat Linux 9 without a problem.
*** Bug 88510 has been marked as a duplicate of this bug. ***
*** Bug 81574 has been marked as a duplicate of this bug. ***
The issue hasn't changed with current Rawhide stuff, what's our stance on it?
Still waiting for upstream to integrate the patch.
Just for your information. The util-linux-2.12pre.tar.gz released 13 July does not contain the patch.
Util-linux 2.12 (the final version) does contain this crypto functionality. Linux kernel 2.6.0-test2 also includes support for loopback encrypted filesystems. The only thin that is missing from util-linux 2.12 is the keysize option allowed by the old CryptoAPI patches (kerneli.org). At this point I am not sure if keysize support will be added to util-linux or not. Again, this stuff works fine with util-linux 2.12 and the 2.6.0-test2 version of the Linux kernel.
The CryptoAPI-aware packages have been updated.
Wow - we can post to the bug again! Current as of Rawhide 2.11y-25. For those tracking this bug, I am attempting to stay current with Rawhide util-linux package, providing binary (i386/i686) and source RPMs for CryptoAPI-aware util-linux for Red Hat Linux 8.0 and 9. If you wish to try them out (I've been using them without a problem for many months with great success) - visit: http://www.brocktec.com/people/myohe/crypto.html
You can find the -29 release (fresh from Rawhide) at: http://www.brocktec.com/people/myohe/crypto.html
Anyone have any luck getting util-linux to function well with the 2.4.22 NPTL rawhide kernel? Evidently, Red Hat's old patches to add CryptoAPI and CryptoLoop to their Red Hat Linux 9 kernel were removed in favor of a 2.4.22 "accepted" CryptoAPI implementation. Util-linux does not like the changes.
> Upstream maintainer says this will be resolved in util-linux-2.12. util-linux-2.12 is out, but rawhide still has 2.11y. Its redhat's turn;-)
Fedora Core 1 has 2.11y too. :(
Alas, you'll need more than just util-linux 2.12; you'll need to patch the FC1 kernel as well. :( The kernel patch, util-linux-2.12 RPMs, and instructions are available here: http://www.pobox.com/~ralston/dev/ See also the messages I posted on 2003-12-03 to fedora-list and fedora-devel-list.
See also bug 111536.
Fedora Core 2 Test 1 also has this bug. Util-linux 2.12pre3 does not contain the modern cryptoloop code. Util-linux 2.12 is still necessary. From the util-linux HISTORY file: util-linux 2.12 * losetup: -p option specifies fd for passphrase [...] * mount: -p option specifies fd for passphrase [...] Version 2.12 of util-linux is available at http://ftp.cwi.nl/aeb/util-linux/util-linux-2.12.tar.gz.
Fedora rawhide now has util-linux-2.12-15. Does this remove the need to install our own version of util-linux? Are the instructions for setting up a encrypted disk the same?
While I've had no problems with util-linux-2.12 in FC2 test2, at this point, it's irrelevant, because the cryptoloop interface has been deprecated in favor of dm-crypt: http://www.andrew.cmu.edu/user/qralston/dev/ The good news is that everything more-or-less works "out of the box" in FC2 test2. We just need cryptsetup (see bug #120487).
I think I'll reopen this bug until I learn more about what the preferred interface is and how we can best support it.
Elliot, make sure to read this: http://kerneltrap.org/node/view/2433 It sums up the situation pretty nicely.
I'm going to see about getting cryptsetup into the device-mapper package. Is there a patch to mount so that people can make use of dm-crypt from fstab? How about easily handling rootfs on dm-crypt?
the best way to get dm-crypt and fstab working nicely would probably be to patch mount (or provide a mount.crypt). This is the interface cryptoloop used. I proposed this idea on the dm-crypt mailing list a while back. Look for the thread "Would like to see mount-like interface to dm_crypt" here: http://news.gmane.org/group/gmane.linux.kernel.device-mapper.dm-crypt/last=/force_load=t I am currently working on patching Red Hat's mkinitrd so that dm-crypt can be used to encrypt one's root partition. I hope to have something working in a week or so. Once that is done I hope to see anaconda support for installing Red Hat/Fedora onto an encrypted root partition.
I just submitted a patch that added encrypted root filesystem support to mkinitrd. See bug #124789. I hope to see the ability to create these filesystems added to anaconda eventually. At this point, they must be created by hand.
At this point I'm only waiting on a patch for 'mount' - the rest is up to others.
Is someone actively writing a patch for mount?
http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/34 is out there, but it requires an unreleased version of cryptsetup, and then it needs to be fed upstream to the util-linux maintainer. Are you game? :)
FYI: The attachment to that article seems to be missing...
The patch is available at: http://www.saout.de/misc/dm-crypt/util-linux-2.12-cryptsetup.patch I plan on trying it today.
The patch mentioned in comments #42 and #43 looks promising. I'm trying to find more about the plans for this patch. For the what it is worth, the patched mount and umount need the following SELinux capabilities: # allow reading of /proc/mounts link allow mount_t proc_t:lnk_file { read }; # manipulate /dev/mapper/control: allow mount_t lvm_control_t:chr_file { read write ioctl }; allow mount_t device_t:chr_file { read write ioctl }; # create a device within /dev/mapper: allow mount_t device_t:dir { write add_name remove_name }; allow mount_t device_t:blk_file { create unlink getattr read }; # allow mount to read password from parent process: allow mount_t user_devpts_t:chr_file { read write getattr }; # allow mount to create /dev/mapper device allow mount_t mount_t:capability { mknod }; # allow mount to look up and set proper context of new /dev/mapper device: allow mount_t file_context_t:file { read getattr }; allow mount_t security_t:dir { search }; allow mount_t security_t:file { read write }; allow mount_t security_t:security { check_context }; allow mount_t device_t:blk_file { relabelfrom }; allow mount_t fixed_disk_device_t:blk_file { relabelto unlink }; # not sure yet why these are needed yet: allow mount_t selinux_config_t:file { read getattr }; allow mount_t mount_t:dir { search }; allow mount_t mount_t:file { getattr read };
Hi, just an update on this bug: For the SELinux changes, please open a separate bug against selinux-policy-targeted (and then we can change this bug to depend on that other one). My main problem right now is that the util-linux patch depends on an unreleased cryptsetup package.
Yes, I have the same problem. I am waiting for the new cryptsetup to be released before I give this too much attention (though I am privately running the code on my own computer). Unfortunately, I have not been able to get a reply from the author concerning the future of cryptsetup or his util-linux patch.
Created attachment 113303 [details] Cryptsetup patch vs. util-linux-2.12p-5 Fedora is now shipping a new fork of cryptsetup, cryptsetup-luks. The upstream package contains the libraries required for this patch. Currently, the Fedora package does not include these libraries, though. See bug #147313, especially comment #3. If one installs the libraries from cryptsetup-luks 1.0 that the RPM leaves out then this patch should build.
The patch sent to upstream maintainer. I'm waiting for response, because I'd rather get this integrated upstream.
Michael, thanks for your patch. I'm not sure with one thing. I think /proc/mount and /etc/mtab should be almost same and we shouldn't mystify users that mounted device is /dev/foo although the real device is /dev/mapper/foo. I think there should not be big difference between mount by cryptsetup+mount and mount with libcryptsetup. I think about something like: mount /dev/mapper/name /mnt/dir -o encrypt,device=/dev/sda2,key_file=foo umount /dev/mapper/name /etc/mtab: /dev/mapper/name on /mnt/dir type ext3 (rw,encrypt,device=/dev/sda2) /etc/fstab: /dev/mapper/name /mnt/dir etx3 encrypt,device=/dev/sda2 but I have to check the others distributions how they resolve it.
Sounds fine. By the way, I did not write the patch. The author is Christophe Saout.
Patch & FC5 src.rpm: http://people.redhat.com/kzak/util-linux-cryptsetup/
*** Bug 179866 has been marked as a duplicate of this bug. ***
any news on fc5?
This bug is quite old. Much has happened since I opened it. The value of patching util-linux may be less now then it was then. In light of, the fact that I can plug in a removable, encrypted drive and GNOME will automatically prompt me for a password and mount it[1], I am really no longer interested in mount itself being patched. Also, encrypted swap[2] has been provided without this patch. Furthermore, on the command line, the cryptsetup, mount sequence is easy to use and I think people are getting used to it. Moving the dm-crypt code to mount probably does not have much value. I may be overlooking some use case here, but my opinion after several years is that util-linux need not be patched. I am going to close this: WONTFIX. [1] https://www.redhat.com/magazine/012oct05/features/hal/ [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127378