Re: Hotplug, 1394, and security

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Jody McIntyre wrote:
> On Sat, Nov 26, 2005 at 12:29:19AM +0100, Stefan Richter wrote:
> 
>>>- Create /dev/bus/ieee1394, which will look approximately like:
>>>0/	- representing the first ieee1394 port
>>>ffc0	- node 0 on first port
>>>ffc1	- node 1
>>>iso	- isochronous traffic
>>>arm	- address range mappings
>>>1/	- second port
>>>ffc0	- ...
>>>iso 
>>>arm
>>
>>What is the purpose of this split of device nodes?
> 
> Different nodes can have different permissions.  For example, a device
> that only implements sbp2 could be accessible only to root.

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.

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.

>>I take it ffc# device nodes are meant for asynchronous read, write, and 
>>lock access. Do asynchronous streams get an extra device node, or should 
>>they be one with the iso device node?
> 
> We don't currently support asynchronous streams via raw1394, but if we

Raw1394 and libraw1394 do support async streams AFAIU from the sources.

> did we could add a "gasp" entry or just have them available via "iso".
> I don't know which is the best approach - it's probably up to whoever
> implements gasp.

[...]
>>>- Should the node entries in /dev/bus/ieee1394 allow complete access to
>>> that node or should we attempt to filter potentially harmful
>>>activities like writes to core CSR registers (RESET_START, timeouts,
>>>etc.)
>>
>>Which activities are harmful, which are not? --- Even read transactions 
>>may be harmful.
> 
> Do you know of any cases where read transactions are harmful?

Read access to the physical address range of PCs with OHCI interface.

> Writes to core CSR space are potentially harmful, at least from a denial
> of service point of view, and I don't see any reason for non-root to do
> them.

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.

>>I really think the only security model which fits the IEEE 1394 
>>architecture (and OHCI architecture) is "all or nothing".
> 
> Neither OSX nor Windows have this type of security problem, and they

I admit I don't know anything about 1394 programming interfaces of other 
OSs.

> both at least claim compliance.  I don't see anything in the spec that
> supports this claim.

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.

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.
-- 
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