A word of warning to udev distributors:
If your distro uses the older "ieee1394" kernel drivers (I think all
distros except Fedora use the old ones, as opposed to the newer
alternative "firewire" a.k.a. "Juju" kernel drivers), then take care
whether you want to use the the current vanilla udev ruleset.
The ieee1394 related rules have been changed by the following commits:
"rules: more changes toward Ubuntu rules merge"
Sun, 21 Dec 2008, in udev 136
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=41e7f55711db043370e1681bb5a97ebdeda5d6d3
This breaks video1394 and dv1394. Fixed by:
"rules: fix ieee1394 rules"
Tue, 5 May 2009, in udev 142
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=d67e32aeb2b64bba0db8840f5e679d3f76b3ffc5
But raw1394 was also disabled for non-root users, and it still is in
current udev:
"rules: do not put raw1394 in "video" group"
Mon, 22 Dec 2008, in udev 136
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=a8cf7cf2c7b4c41c14508a808b09a5fa9256a024
This change forces users
- either to modify udev rules to revert this,
- or to run video acquisition software and other A/V applications as
root.
Nice.
Yes, there are security considerations regarding the older ieee1394
drivers. But first of all, these security considerations have nothing
to do with access permission of /dev/raw1394. Instead, they have to do
with how the ohci1394 enables physical DMA on OHCI-1394 host
controllers. Physical DMA is one of the DMA modes offered by OHCI-1394
drivers and it is necessary for the sbp2 driver (FireWire storage) to
function.
By default, the ohci1394 driver switches physical DMA on without
filters. Alternatively, it can be switched off by a module parameter
but then sbp2 won't work anymore.
When physical DMA is switched on, remote nodes can read and write any
memory to which the OHCI-1394 PCI device has access to. On systems
without IOMMU, this is the first 4 GB of physical memory of course.
Basically, physical DMA lets the OHCI-1394 controller act as a bus
bridge between PCI and 1394; the 1394 port becomes somewhat of a plug
into PCI.
In the past, this nifty OHCI-1394 feature has been used in one or two
media-effective demos of how a FireWire iPod with modified firmware
(e.g. runing ucLinux) can be used to own an Apple Mac. Nothing else
than these demos ever came out of this. Apple have since fixed their
OHCI-1394 driver implementation to properly filter physical DMA.
We fixed this too eventually --- but not in ohci1394, only by providing
the new alternative firewire driver stack which has physical DMA filtering.
Now, people who are concerned about this (arguably mostly theoretical)
FireWire security issue could have
- sat down to learn what the issue is about,
- ported the fix from the new firewire drivers to the old 1394
drivers,
- or helped getting the new firewire drivers ready to fully replace
the old drivers.
But wait, why actually fix the issue if you can instead provide a
workaround which (a) demonstrates that you don't actually know what you
are doing, (b) doesn't actually fix the problem, (c) entirely destroys
the ability to run FireWire enabled software --- desktop/ consumer
oriented software as well as professional software.
This workaround of making /dev/raw1394 accessible to root improves
security only in one respect: The hole that is opened by ohci1394 can
now no longer be used by a client terminal which runs raw1394 (modulo
root on this terminal).¹ Your Linux box is still vulnerable to any
other of such terminals, be it another Linux box with privileged or
unprivileged access to raw1394, or a Windows PC or Mac or iPod or
whatever with respective hacker toolset.
¹) As mentioned in the changelog of the udev commit in question, based
on a comment which I made at the respective Ubuntu bug tracker item, the
terminal can also be the same PC if it has at least two FireWire
controllers which are the plugged together.
PS:
Perhaps I should finally copy the physical DMA filtering from the new
drivers to the old drivers --- but then I have endless other things to
do, things with actual practical importance. Like getting the new
drivers fully featured. However, I'm seeing an increase of trivial end
user support questions coming onto myself and all the Linux 1394
libraries & applications developers in the near future. --- One way or
another, we need to get back usable FireWire access defaults.
--
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
