On Mon, May 08, 2006 at 09:31:02AM +0600, Alexander E. Patrakov wrote: > > 1) What should be done with the "usb" group in the short term. > > Possible answers: > > a) keep it in LFS (then LFS should assign the group, and BLFS should show > how to override that, as in the "scanner" example),
This is the short term answer. We are getting too close to release to change. > b) move to BLFS (in this case, BLFS should create this group and add a > rule: SUBSYSTEM=="usb_device", GROUP="usb", and there is already some > example text about the "scanner" group), This should be in post-6.2. > 2) What should be done with the "usb" group in the long term. > > Here no discussion is possible. It was introduced as a hack to make USB > scanners and cameras work for non-root without the "hotplug" package in > LFS-6.0. It gives too-broad rights, and should be either removed completely > or strongly advised to remain empty. Following up from a chat with Alex: This is a tough call. There are always ways to circumvent security. Alex has mentioned the ability to re-flash a USB device and thereby intentionally destroy it. While physical security is outside the scope of the book, we are left with a situation where a person authorized to use the computer can potentially wreak havok. This ability would be no different than if that person had access to the device via the scanenr or camera group, though. So we have 2 potential situations where a USB group lessens security: 1) A person isn't supposed to have access to a camera, but they are allowed access to a printer. With a USB group it's all or nothing. 2) Raw access to USB disks regardless of access via the scsi layer. Someone not in the disk group can still hose this device. This is a re-iteration of the above just with a different example. It should be noted that this is a non-trivial sabotage and not one that will be done accidentally by an unsuspecting user. It requires communicating via libusb, or my hand mangling the ioctls. > There is already an example how to override the group, so scanners won't be > made non-functional. In the future, we should mass-install rules for SANE > and libgphoto2. Text will be posted after solving the first (political) > issue I raised. I'd rather see an example rule in the book, and then text showing the person how to retrieve the VendorID. That way we don't install a thousand udev rules. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
