Bug 56698

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