Re: Hotplug, 1394, and security

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

Jody McIntyre wrote:
...
> Currently, /dev/raw1394 offers full access to the entire 1394 bus from
> userland.  User programs (such as audio and video software) use this
> device to access other nodes on the bus, and must have full access to
> it.  This is clearly bad from a security point of view: there's nothing
> stopping a malicious program from accessing other nodes, such as sbp2
> disks, etc.
> 
> Also, we need to decide how best to handle new devices, such as the 1394
> audio devices being supported by the FreeBob project.  The prototype
> implementation simply runs as a daemon that waits for bus resets, probes
> devices, and provides information on AV/C audio devices to the streaming
> driver.  I'd like to eliminate the need for the daemon by having hotplug
> do some of this work, and the streaming driver the rest.

These two issues might be related, but I think we should keep their 
discussion separate as far as possible.

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

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?

> - Read and parse complete ConfigROMs from the kernel and make this
>   information available via sysfs.  Thoughts on how best to represent
> this would be appreciated.

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.

> - Send hotplug events when new devices are added, devices are removed,
>   and when the ConfigROM of an existing device changes.

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

> - Hotplug will use the information in sysfs to manage /dev/bus/1394
>   nodes.
> 
> - The FreeBob streaming driver finds AV/C devices using the sysfs
>   information and performs AV/C discovery/enumeration to see if they are
> audio devices.
> 
> - /dev/raw1394 will continue to exist and provide complete access to all
>   buses, but will normally be accessible to root only.

See below...

> - Enhance libraw1394 (which all userland programs that access the bus
>   ought to be using) to use the /dev/bus/ieee1394 devices when
> /dev/raw1394 is inaccessible or unavailable.
> 
> Open questions:
>  
> - Should the kernel be dealing with ConfigROMs?  I think so, but an
>   alternative is to have a utility linked against libraw1394 that
> hotplug uses to read and manage ConfigROM information, instead of using
> sysfs.

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.

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

I am very sceptical that there is a way to apply a filter which still 
allows at least most common FireWire applications _and_ provides more 
than a false sense of security.

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.

I really think the only security model which fits the IEEE 1394 
architecture (and OHCI architecture) is "all or nothing".

> - Should we also do AV/C discovery and enumeration?  This is necessary
>   to distinguish between AV/C audio devices and video cameras, but I
> don't think these need different permissions.
> 
> - This does push a lot of the work currently done by the FreeBob daemon
>   down into the streaming driver (presumably via libfreebobctl.)  Would
> it be better to have hotplug launch something to do this work?

Well, I can't comment on AV/C specific topics.
-- 
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