Re: Hotplug, 1394, and security

[Jody McIntyre <scjody@modernduck.com>]

On Sun, Nov 27, 2005 at 02:39:54PM +0100, Stefan Richter wrote:

> OK, that's sensible. Although users/ admins should to be aware that 
> device files of nodes with different subunits inherit permissions of 
> their least protected subunit. Of course there are not many 
> multi-protocol devices, except PCs. I.e. if you ran an AV/C unit on a 
> remote PC (or on the local PC), the local Linux PC would grant liberal 
> access to it.

It's really up to whoever configures udev.  Do people really run AV/C
targets (as opposed to controllers) on their PCs?  If so then yes, that
would be difficult to secure.

> How are permissions handled during the time after a bus reset until unit 
> capabilities are known? They should be probably reverted to a default 
> mask. This default mask could be the same as for /dev/raw1394, i.e. 
> usually restricted to access by root. Unit capabilities have to be 
> determined as fast as possible in order to restore useful permissions.

Again, it's up to udev.  What you describe sounds like a sane default.

> >We don't currently support asynchronous streams via raw1394, but if we
> 
> Raw1394 and libraw1394 do support async streams AFAIU from the sources.

Oh, right.  I misremembered what I read in Steve Kinneberg's email
describing the current state (
http://marc.theaimsgroup.com/?l=linux1394-devel&m\x111923772101941&w=2 ).

Let's leave it in "iso" for now.  It should be fairly easy to add a
"gasp" device in the future if needed.

> >Do you know of any cases where read transactions are harmful?
> 
> Read access to the physical address range of PCs with OHCI interface.

Sure, but as far as I know, non-root processes do not need any access to
other PCs on the bus.

> OK, it is sensible to deny write access to well-known registers. But 
> what would enforce this policy? The kernel or userspace? Userspace can't 
> really do that since a patched libraw1394 suffices to circumvent it.

The kernel.  What I propose is that writes via /dev/raw1394 would always
work, and /dev/bus/ieee1394/whatever would be filtered.  Normally, only
root would be able to access /dev/raw1394.  If we make libraw1394
"prefer" /dev/raw1394 when accessible, the following is possible:
 - root can write to these registers
 - other users can not.

> IEEE 1394 itself does not explicitly deal with security matters, except 
> for IEEE 1394a annex C1. This is 2/3rd of a page, out of 974 pages of 
> IEEE 1394 including its two amendments. (OTOH a good security spec 
> should be brief... Does it mean 1394 security is inherently strong? :-) 
> Security implications of the OHCI spec's physical DMA feature have been 
> discussed at linux1394-devel recently. The SBP-2 spec offers only 
> marginal security features. I am not familiar with other protocol specs.

Yes, therefore my proposal is not in violation of IEEE 1394, 1394a, or
1394b.

And yeah, this annex is the reason you need to have a non 1394a chipset
(pcilynx) to snoop the bus :(

> BTW, does anybody know of 1394 related protocols which require 
> application layer software (except bus and node management layer) to 
> issue bus resets, or to send or receive physical layer packets (1394a 
> 4.3.4)? I hope there are none.

Me too :)  I'm hoping these can remain /dev/raw1394 only.

Cheers,
Jody

> -- 
> Stefan Richter
> -===-=-=-= =-= =-=
> http://arcgraph.de/sr/

-- 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel