Hotplug, 1394, and security

Hotplug, 1394, and security

[Jody McIntyre]

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

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

Re: Hotplug, 1394, and security

[Kurt Konolige]

Not sure I understand everything about this proposal, but in general 
DCAM video devices need access to raw1394 to read and write data to the 
device.  This is independent of the video1394 driver, which handles the 
ISO traffic.  Would this ability be preserved in libraw1394?

Cheers --Kurt

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 :)
> 
> 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
> _______________________________________________
> mailing list linux1394-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux1394-devel
> 


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

Re: Hotplug, 1394, and security

[Jody McIntyre]

On Fri, Nov 25, 2005 at 01:49:49PM -0800, Kurt Konolige wrote:
> Not sure I understand everything about this proposal, but in general 
> DCAM video devices need access to raw1394 to read and write data to the 
> device.  This is independent of the video1394 driver, which handles the 
> ISO traffic.  Would this ability be preserved in libraw1394?

Yes.

Jody

> Cheers --Kurt


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

Re: Hotplug, 1394, and security

[Stefan Richter]

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

Re: Hotplug, 1394, and security

[Kurt Konolige]

Sorry, I should have been more clear.  Will libraw1394 access be 
restricted to root, as a default policy?  There are user programs that 
need access to libraw read/write, at least for DCAM-compliant devices.

Cheers --Kurt

Jody McIntyre wrote:
> On Fri, Nov 25, 2005 at 01:49:49PM -0800, Kurt Konolige wrote:
> 
>>Not sure I understand everything about this proposal, but in general 
>>DCAM video devices need access to raw1394 to read and write data to the 
>>device.  This is independent of the video1394 driver, which handles the 
>>ISO traffic.  Would this ability be preserved in libraw1394?
> 
> 
> Yes.
> 
> Jody
> 
> 
>>Cheers --Kurt
> 
> 


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

Re: Hotplug, 1394, and security

[Stefan Richter]

Kurt Konolige wrote:
> Will libraw1394 access be 
> restricted to root, as a default policy?  There are user programs that 
> need access to libraw read/write, at least for DCAM-compliant devices.

In my opinion, the kernel should not enforce one or the other policy. As 
long as a policy (e.g. security policy) can be controlled in userspace, 
control it in userspace.
-- 
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

Re: Hotplug, 1394, and security

[Jody McIntyre]

On Sat, Nov 26, 2005 at 08:07:58AM +0100, Stefan Richter wrote:
> Kurt Konolige wrote:
> >Will libraw1394 access be 
> >restricted to root, as a default policy?  There are user programs that 
> >need access to libraw read/write, at least for DCAM-compliant devices.
> 
> In my opinion, the kernel should not enforce one or the other policy. As 
> long as a policy (e.g. security policy) can be controlled in userspace, 
> control it in userspace.

I agree.  It's really up to your udev configuration.  You could even
continue to give your video users full /dev/raw1394 access (but you
wouldn't have to.)

What do you mean by "DCAM-compliant"?  IEC 61883?

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

Re: Hotplug, 1394, and security

[Jody McIntyre]

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

Re: Hotplug, 1394, and security

[Kurt Konolige]

The 1394 Trade Association puts out something called the "IIDC 
1394-based Camera Specification", which most folks just call the DCAM 
spec.  You control the camera by reading and writing into its 1394 
address space, which is structured according to this spec.  I think IEC 
61883 defines a wrapper structure of iso packets that hold video; 
devices with uncompressed video typically don't use it.

At any rate, user space control over the camera hinges on writing to 
/dev/raw1394, to set camera parameters.  I frequently have to change the 
  default /dev/raw1394 access controls on new Linux systems, to enable 
DCAM controls.  It would be a pain if this were restricted to root access.

Cheers --Kurt

Jody McIntyre wrote:
> On Sat, Nov 26, 2005 at 08:07:58AM +0100, Stefan Richter wrote:
> 
>>Kurt Konolige wrote:
>>
>>>Will libraw1394 access be 
>>>restricted to root, as a default policy?  There are user programs that 
>>>need access to libraw read/write, at least for DCAM-compliant devices.
>>
>>In my opinion, the kernel should not enforce one or the other policy. As 
>>long as a policy (e.g. security policy) can be controlled in userspace, 
>>control it in userspace.
> 
> 
> I agree.  It's really up to your udev configuration.  You could even
> continue to give your video users full /dev/raw1394 access (but you
> wouldn't have to.)
> 
> What do you mean by "DCAM-compliant"?  IEC 61883?
> 
> 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

Re: Hotplug, 1394, and security

[Stefan Richter]

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

Re: Hotplug, 1394, and security

[Stefan Richter]

I wrote:
> 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.

An alternative, more secure policy would be to apply the permissions 
according to the most protected subunit.

> How are permissions handled during the time after a bus reset until unit 
> capabilities are known?

A related issue are subunits whose type is unknown to the udev helper.
-- 
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

Re: Hotplug, 1394, and security

[Stefan Richter]

Kurt Konolige wrote:
> The 1394 Trade Association puts out something called the "IIDC 
> 1394-based Camera Specification", which most folks just call the DCAM 
> spec.  You control the camera by reading and writing into its 1394 
> address space, which is structured according to this spec.  I think IEC 
> 61883 defines a wrapper structure of iso packets that hold video; 
> devices with uncompressed video typically don't use it.
> 
> At any rate, user space control over the camera hinges on writing to 
> /dev/raw1394, to set camera parameters.  I frequently have to change the 
>  default /dev/raw1394 access controls on new Linux systems, to enable 
> DCAM controls.  It would be a pain if this were restricted to root access.

If I understand Jody's proposal correctly, libraw could transparently 
try to send those requests through the extra 
/dev/bus/ieee1394/${bus}/${nodeID} devices if available. An udev helper 
should become aware of IIDC compliant units and adjust node permissions 
according to local policy, on the fly.
-- 
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

Re: Hotplug, 1394, and security

[Jody McIntyre]

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

Re: Hotplug, 1394, and security

[Stefan Richter]

Jody McIntyre wrote:
> On Sun, Nov 27, 2005 at 02:39:54PM +0100, Stefan Richter wrote:
>>Raw1394 and libraw1394 do support async streams AFAIU from the sources.
...
> Let's leave it in "iso" for now. 

What about naming it "streams" then?

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

This means furthermore that only privileged users (e.g. root) should be 
allowed to add unit directories to the local configROM, or generally to 
manipulate the ROM.

OTOH the problem with phys DMA should rather be solved in the driver 
stack which enables phys DMA.

...
>>IEEE 1394 itself does not explicitly deal with security matters,
...
> Yes, therefore my proposal is not in violation of IEEE 1394, 1394a, or
> 1394b.

No, it isn't, and I never wanted to imply the contrary. I just assumed 
so far that IEEE 1394 makes it very difficult to combine security and 
functionality. But what you describe sounds feasible.
-- 
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

Re: Hotplug, 1394, and security

[Jody McIntyre]

On Tue, Nov 29, 2005 at 01:08:03AM +0100, Stefan Richter wrote:

> What about naming it "streams" then?

OK.

> >Sure, but as far as I know, non-root processes do not need any access to
> >other PCs on the bus.
> 
> This means furthermore that only privileged users (e.g. root) should be 
> allowed to add unit directories to the local configROM, or generally to 
> manipulate the ROM.

I don't see how one follows from the other, but yes, that was my
intent.  Anything other than "streams", "arm", and async traffic will be
/dev/raw1394-only (or typically, root-only.)  If it's necessary to add
more types of packets to the list, we can certainly do that.

> OTOH the problem with phys DMA should rather be solved in the driver 
> stack which enables phys DMA.

I agree.  Unfortunately it's impossible to solve for everyone.  Most
sbp2 users will want it enabled, but security-conscious people will want
it off.  I don't know what a sane default is (so let's stick with what
we've got.. in any case, that's beyond the scope of this discussion.

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

Re: Hotplug, 1394, and security

[Stefan Richter]

Jody McIntyre wrote:
> On Tue, Nov 29, 2005 at 01:08:03AM +0100, Stefan Richter wrote:
>>>Sure, but as far as I know, non-root processes do not need any access to
>>>other PCs on the bus.
>>
>>This means furthermore that only privileged users (e.g. root) should be 
>>allowed to add unit directories to the local configROM, or generally to 
>>manipulate the ROM.
> 
> I don't see how one follows from the other, but yes, that was my
> intent.

Otherwise, AV/C entries or the like could be added which would weaken 
access restrictions to the local node.
-- 
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