Re: Hotplug, 1394, and security

[Jody McIntyre <scjody@modernduck.com>]

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.

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

> According to Linus, binary sysfs attributes instead of the usual 
> plain-text sysfs attributes are permissible for certain purposes. Alas I 
> don't have a lkml archive link readily available... However there are 
> probably alternatives to sysfs. Of course a representation of config 
> ROMs by single-value plain-text sysfs attributes is surely possible but 
> obviously not quite a lean solution.

I'd really rather parse them out.  The problem is that they don't always
map cleanly into a filesystem-like structure, due to non-unique
descriptors, etc.

> (Some ROM changes already cause hotplug events, basically if unit 
> directories are added or removed. But AFAIU previous discussions, this 
> is less than what is desirable to have reported through hotplug, at 
> least from AV/C applications' perspective.)

Yes.  Whether or not to do AV/C enumeration is an open question.

> Keep one thing in mind: The kernel should (and can) have only very 
> limited knowledge about the meaning of config ROMs. Therefore it can 
> assist only to a limited degree.
> 
> It would probably be beneficial to make the ROM caches that already 
> exist in the kernel available to userspace. But the kernel's ROM 
> fetching infrastructure really needs to be more robust if it is to 
> fulfill such new requirements. IMO a multithreaded implementation would 
> be desirable.

Yes it would.  Also we could do what OSX does and fetch the entire ROM
into memory sequentially then parse it later.

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

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.

> Why not stick with the current security model? I.e. raw1394 as a 
> all-or-nothing thing. You as a distributor or administrator may select a 
> group of software that you trust enough to access raw1394, by means of 
> group permissions. I.e. let /dev/raw1394 be owned and read/writable by a 
> group, let trusted application executables be owned by the same group, 
> and set their set-group-ID flag.

All-or-nothing does not offer enough control for many purposes.  For
example, consider the case of an sbp2 device and an AV/C video camera on
the same bus.  In order to allow users to control the video camera, an
administrator must currently also allow full access to the sbp2 device,
but there's no legitimate reason for anyone to be directly accessing the
sbp2 device in the first place.

> 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
both at least claim compliance.  I don't see anything in the spec that
supports this claim.

Cheers,
Jody


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