ironkey requires root access to unlock

[Joel Ebel]

Binary package hint: udev

The IronKey (https://www.ironkey.com/) requires write access to the block device to unlock. Since current udev rules place the ironkey (and all USB storage devices) in the disk group, and standard users are not in the disk group by default (nor should they be since direct access to a disk block device is dangerous and rarely required), unlocking an ironkey currently requires root permissions. The attached udev rule places the ironkey in the plugdev group, giving a user who is in plugdev (most users) permission to unlock the device without root access.

[Scott James Remnant (Canonical) (canonical-scott)]

The default permissions are the way they are for many reasons.

Users are granted ACLs on USB devices inserted while they are logged in, so this should not be needed anyway.

[Joel Ebel (jbebel)]

Scott, I don't think you are correct. Without this rule, I do not have permission to unlock an ironkey without the use of sudo. When I add the attached rule, sudo is not required to unlock the drive.

When inserted, /dev/sdb is owned by root:disk. This is done by udev, specifically by 40-permissions.rules line 47:
ATTRS{type}=="0", GROUP="disk"

Users are typically not in group disk since having access directly to the block devices is not required for normal use. The attached rule puts only the ironkey in group plugdev, which users are typically in, allowing them direct access to the block device, which is required to unlock the drive.

[Joel Ebel (jbebel)]

I also want to make it clear, since it seems you didn't look at the attachment, that I am not proposing any large sweeping change to policy, but only to the specific USB device ID of the ironkey, since it is unique in its requirements.

[Scott James Remnant (Canonical) (canonical-scott)]

The udev rule you attached is invalid according to policy, because it places the device in the deprecated "plugdev" group. Our policy is to *NOT* use groups for device access in this manner, but to use ACLs on devices instead.

Please plug in your device (without any extra udev rules) and run the following, providing the output (changing X to whatever letter is assigned)

  for DEV in /dev/sdX*; do
    ls -l $DEV
    getfacl $DEV
    udevinfo -q all -n $DEV
  done

[Joel Ebel (jbebel)]

When inserted, the ironkey creates two block devices. In my case, /dev/scd1, which is an emulated USB cd-rom containing the unlock program, which gets automatically mounted, and /dev/sdb which appears as a removeable media usb storage device. To unlock, you need write access directly to /dev/sdb. Once unlocked, the media is "inserted" into /dev/sdb. It is an unpartitioned disk, by default, so there is no partition table on /dev/sdb. I'll include the output of /dev/sdb and /dev/scd1. It appears that my user (jbebel) gets write access to /dev/scd1, but not /dev/sdb.

brw-rw---- 1 root disk 8, 16 2008-09-30 11:31 /dev/sdb
getfacl: Removing leading '/' from absolute path names
# file: dev/sdb
# owner: root
# group: disk
user::rw-
group::rw-
other::---

P: /block/sdb
N: sdb
S: disk/by-id/usb-IronKey_Secure_Drive_851D01065a6817201217-0:1
S: disk/by-path/pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:1
E: DEVTYPE=disk
E: ID_VENDOR=IronKey
E: ID_MODEL=Secure_Drive
E: ID_REVISION=1.00
E: ID_SERIAL=IronKey_Secure_Drive_851D01065a6817201217-0:1
E: ID_SERIAL_SHORT=851D01065a6817201217
E: ID_TYPE=disk
E: ID_INSTANCE=0:1
E: ID_BUS=usb
E: ID_PATH=pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:1

brw-rw----+ 1 root cdrom 11, 1 2008-09-30 11:31 /dev/scd1
getfacl: Removing leading '/' from absolute path names
# file: dev/scd1
# owner: root
# group: cdrom
user::rw-
user:jbebel:rw-
group::rw-
mask::rw-
other::---

P: /block/sr1
N: scd1
S: disk/by-id/usb-IronKey_Secure_Drive_851D01065a6817201217-0:0
S: disk/by-path/pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0
S: sr1
S: cdrom1
S: cdrom2
E: ID_CDROM=1
E: ID_CDROM_MRW=1
E: ID_CDROM_MRW_W=1
E: ID_CDROM_RAM=1
E: DEVTYPE=disk
E: ID_VENDOR=IronKey
E: ID_MODEL=Secure_Drive
E: ID_REVISION=1.00
E: ID_SERIAL=IronKey_Secure_Drive_851D01065a6817201217-0:0
E: ID_SERIAL_SHORT=851D01065a6817201217
E: ID_TYPE=cd
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_PATH=pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0
E: GENERATED=1

[Joel Ebel (jbebel)]

Hmm. Not sure why launchpad wanted to apply this to aptitude. That is a mistake. It should only apply to udev. I don't see a way to remove the aptitude package from the bug though.

[Scott James Remnant (Canonical) (canonical-scott)]

Missing ACL?

Could you do udevinfo -a on both nodes?

[Joel Ebel (jbebel)]

I running this on hardy. Maybe things have changed in intrepid, but the behavior of the ACLs on the ironkey don't appear different than on a standard USB flash drive, and as previously stated, I wouldn't expect a typical user to get write access directly to the block device of a normal USB flash drive. I'll attach udevinfo for the ironkey devices.

[Joel Ebel (jbebel)]

I tested with intrepid and had a nearly identical result, with the small exception that I was not granted write access to /dev/scd1. Since that's not necessary or even useful, it doesn't particularly matter.