Archaic wrote: > 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.
>From this discussion, is seems there needs to be a separate group for each device and users be given appropriate permissions for those devices. This seems to be a general security administration issue, not a LFS or BLFS issue. It may be appropriate for HLFS. Adding every conceivable security issue may be beyond the book(s), especially when we are basically talking about physical security. If many people can touch the machine, can it really be secure? Usually there are servers and workstations. Servers generally won't have cameras, scanners, etc. Workstations usually only have one user. It would appear that the occurrence of this type of risk is relatively rare. Perhaps this should be covered in a section called "Removable Devices and Security." Do I have any volunteers to write it? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
