Re: [Freebob-devel] Hotplug, 1394, and security

[Austin Acton <austin.acton@utoronto.ca>]

On Fri, 2005-11-25 at 16:32 -0500, Jody McIntyre wrote:
> Here are my thoughts on how to solve the current problems with 1394
> hotplug and raw1394 security.  I am starting work on an implementation
> but am posting this now in case I'm completely on the wrong track or
> something.
> 
> 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.
> 
> Here's what I propose:
> 
> - 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
> 
> - 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.
> 
> - Send hotplug events when new devices are added, devices are removed,
>   and when the ConfigROM of an existing device changes.
> 
> - 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.
> 
> - 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.
> 
> - 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.)
> 
> - 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?
> 
> 
> All comments welcome :)

This may not matter, but just a heads up.

Some distros maybe dropping hotplug completely in the future and
replacing all hotplug events with udev rules.

Mandriva has already done this.

Austin



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