Bug 56698 - Losetup and util-linux are not crypto aware.
Losetup and util-linux are not crypto aware.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
: FutureFeature
: 74776 78544 78550 78552 81574 88510 179866 (view as bug list)
Depends On: 111536 127378
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-25 07:57 EST by W. Michael Petullo
Modified: 2007-11-30 17:10 EST (History)
17 users (show)

See Also:
Fixed In Version: 2.12-2
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-26 16:45:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
util-linux-2.11y-cryptoapi.patch (63.62 KB, patch)
2003-01-22 02:15 EST, James Ralston
no flags Details | Diff
Cryptsetup patch vs. util-linux-2.12p-5 (14.99 KB, patch)
2005-04-17 22:29 EDT, W. Michael Petullo
no flags Details | Diff

  None (edit)
Description W. Michael Petullo 2001-11-25 07:57:54 EST
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:
Comment 1 Elliot Lee 2002-01-04 16:03:07 EST
There may be export issues I don't know of... I'd rather just get this
integrated upstream.
Comment 2 Elliot Lee 2002-01-29 16:39:44 EST
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.
Comment 3 Elliot Lee 2002-10-13 12:05:50 EDT
*** Bug 74776 has been marked as a duplicate of this bug. ***
Comment 4 Elliot Lee 2002-12-03 17:17:17 EST
*** Bug 78552 has been marked as a duplicate of this bug. ***
Comment 5 Elliot Lee 2002-12-09 12:56:02 EST
*** Bug 78544 has been marked as a duplicate of this bug. ***
Comment 6 Elliot Lee 2002-12-09 13:58:59 EST
*** Bug 78550 has been marked as a duplicate of this bug. ***
Comment 7 Elliot Lee 2002-12-09 14:29:32 EST
Upstream maintainer says this will be resolved in util-linux-2.12.
Comment 8 James Ralston 2003-01-20 00:24:11 EST
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.)
Comment 9 Need Real Name 2003-01-20 04:31:36 EST
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
Comment 10 James Ralston 2003-01-22 02:13:17 EST
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@pobox.com> 2.11y-2.int
+- add the CryptoAPI patch
+
 * Mon Jan 13 2003 Elliot Lee <sopwith@redhat.com> 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.
Comment 11 James Ralston 2003-01-22 02:15:09 EST
Created attachment 89508 [details]
util-linux-2.11y-cryptoapi.patch
Comment 12 Michael Lee Yohe 2003-01-22 11:52:27 EST
Confirming - the patch works just as expected without a problem.  No compilation
warnings nor errors as a result of the patch.
Comment 13 Need Real Name 2003-01-24 09:44:05 EST
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.
Comment 14 Gerald Teschl 2003-03-15 13:09:41 EST
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.
Comment 15 Gerald Teschl 2003-06-16 13:28:25 EDT
Since there is no util-linux-2.12 in sight, please reconside rhtis for the
next release.
Comment 16 Michael Lee Yohe 2003-06-16 15:56:17 EDT
I'm still using James's patch for util-linux (losetup and mount) under Red Hat
Linux 9 without a problem.
Comment 17 Nils Philippsen 2003-07-12 09:48:41 EDT
*** Bug 88510 has been marked as a duplicate of this bug. ***
Comment 18 Nils Philippsen 2003-07-12 09:50:12 EDT
*** Bug 81574 has been marked as a duplicate of this bug. ***
Comment 19 Nils Philippsen 2003-07-12 09:54:06 EDT
The issue hasn't changed with current Rawhide stuff, what's our stance on it?
Comment 20 Elliot Lee 2003-07-14 09:12:34 EDT
Still waiting for upstream to integrate the patch.
Comment 21 Dennis Björklund 2003-08-11 08:53:14 EDT
Just for your information. The util-linux-2.12pre.tar.gz released 13 July does
not contain the patch.
Comment 22 W. Michael Petullo 2003-08-12 08:41:52 EDT
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.
Comment 23 Michael Lee Yohe 2003-08-12 10:35:35 EDT
The CryptoAPI-aware packages have been updated.
Comment 24 Michael Lee Yohe 2003-08-12 10:40:45 EDT
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
Comment 25 Michael Lee Yohe 2003-09-12 11:18:26 EDT
You can find the -29 release (fresh from Rawhide) at:

http://www.brocktec.com/people/myohe/crypto.html
Comment 26 Michael Lee Yohe 2003-10-20 17:14:07 EDT
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.
Comment 27 Gerald Teschl 2003-10-21 17:43:14 EDT
> 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;-)
Comment 28 Need Real Name 2003-11-11 23:22:24 EST
Fedora Core 1 has 2.11y too. :(
Comment 29 James Ralston 2003-12-03 04:21:39 EST
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.
Comment 30 James Ralston 2003-12-04 19:00:10 EST
See also bug 111536.
Comment 31 W. Michael Petullo 2004-02-12 12:14:58 EST
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.
Comment 32 Brian G. Anderson 2004-04-05 09:43:32 EDT
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?
Comment 33 James Ralston 2004-04-09 06:53:16 EDT
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).
Comment 34 Elliot Lee 2004-04-11 16:29:11 EDT
I think I'll reopen this bug until I learn more about what the
preferred interface is and how we can best support it.
Comment 35 James Ralston 2004-04-12 05:05:13 EDT
Elliot, make sure to read this:

http://kerneltrap.org/node/view/2433

It sums up the situation pretty nicely.
Comment 36 Elliot Lee 2004-05-24 15:55:35 EDT
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?
Comment 37 W. Michael Petullo 2004-05-24 16:52:15 EDT
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.
Comment 38 W. Michael Petullo 2004-05-29 22:45:52 EDT
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.
Comment 39 Elliot Lee 2004-06-03 16:22:31 EDT
At this point I'm only waiting on a patch for 'mount' - the rest is up
to others.
Comment 40 W. Michael Petullo 2004-06-17 09:15:44 EDT
Is someone actively writing a patch for mount?
Comment 41 Elliot Lee 2004-07-07 11:27:03 EDT
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? :)
Comment 42 Nils Philippsen 2004-07-08 06:57:14 EDT
FYI: The attachment to that article seems to be missing...
Comment 43 W. Michael Petullo 2004-07-08 10:04:43 EDT
The patch is available at:
	http://www.saout.de/misc/dm-crypt/util-linux-2.12-cryptsetup.patch

I plan on trying it today.
Comment 44 W. Michael Petullo 2004-07-08 22:25:21 EDT
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 };
Comment 45 Elliot Lee 2004-08-20 12:12:50 EDT
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.
Comment 46 W. Michael Petullo 2004-08-20 12:18:19 EDT
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.
Comment 47 W. Michael Petullo 2005-04-17 22:29:51 EDT
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.
Comment 48 Karel Zak 2005-04-18 16:18:17 EDT
The patch sent to upstream maintainer. I'm waiting for response, because I'd
rather get this integrated upstream.
Comment 49 Karel Zak 2005-08-08 09:23:49 EDT
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.
Comment 50 W. Michael Petullo 2005-08-09 13:16:34 EDT
Sounds fine.  By the way, I did not write the patch.  The author is Christophe 
Saout.
Comment 51 Karel Zak 2005-08-26 06:20:44 EDT
Patch & FC5 src.rpm:

   http://people.redhat.com/kzak/util-linux-cryptsetup/
Comment 52 Karel Zak 2006-02-07 04:29:00 EST
*** Bug 179866 has been marked as a duplicate of this bug. ***
Comment 53 Levente Farkas 2006-03-30 04:43:51 EST
any news on fc5?
Comment 54 W. Michael Petullo 2006-08-26 16:45:41 EDT
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

Note You need to log in before you can comment on or make changes to this bug.