ngd 510 new stuff

[Andreas Beckmann]

Hi Luca,

the 510 driver comes with two new things:

* libnvidia-compiler-next.so.#VERSION#

which has the same soname as libnvidia-compiler.so.#VERSION#
How is that intended to be used?

* nvidia-powerd

comes with a nvidia-dbus.conf that lintian does not like

<busconfig>
   <type>system</type>
   <policy context="default">
     <allow own="nvidia.powerd.client"/>
     <allow own="nvidia.powerd.server"/>
     <allow send_requested_reply="true"/>
     <allow receive_requested_reply="true"/>
   </policy>
</busconfig>

E: nvidia-powerd: dbus-policy-excessively-broad usr/share/dbus-1/system.d/nvidia-dbus.conf (rule 3) <policy context="default"><allow send_requested_reply="true"/>
N:
N:   The package contains D-Bus policy configuration that matches broad classes
N:   of messages. This will cause strange side-effects, is almost certainly
N:   unintended, and is a probable security flaw.
N:
N:   For instance,
N:
N:     <policy user="daemon">
N:       <allow send_type="method_call"/>
N:       <allow send_destination="com.example.Bees"/>
N:     </policy>
N:
N:   in any system bus policy file would allow the daemon user to send any
N:   method call to any service, including method calls which are meant to be
N:   restricted to root-only for security, such as
N:   org.freedesktop.systemd1.Manager.StartTransientUnit. (In addition, it
N:   allows that user to send any message to the com.example.Bees service.)
N:
N:   The intended policy for that particular example was probably more like
N:
N:     <policy user="daemon">
N:       <allow send_type="method_call" send_destination="com.example.Bees"/>
N:     </policy>
N:
N:   which correctly allows method calls to that particular service only.
N:
N:   Please refer to http://www.openwall.com/lists/oss-security/2015/01/27/25
N:   for details.
N:
N:   Visibility: error
N:   Show-Always: no
N:   Check: desktop/dbus

W: nvidia-powerd: dbus-policy-without-send-destination usr/share/dbus-1/system.d/nvidia-dbus.conf (rule 3) <policy context="default"><allow send_requested_reply="true"/>
N:
N:   The package contains D-Bus policy configuration that uses one of the
N:   send_* conditions, but does not specify a send_destination, and is not
N:   specific to root.
N:
N:   Rules of the form
N:
N:     <allow send_interface="com.example.MyInterface"/>
N:
N:   allow messages with the given interface to be sent to *any* service, not
N:   just the one installing the rule, which is rarely what was intended.
N:
N:   Similarly, on the system bus, rules of the form
N:
N:     <deny send_interface="com.example.MyInterface"/>
N:
N:   are redundant with the system bus's default-deny policy, and have
N:   unintended effects on other services.
N:
N:   This check ignores rules of the form
N:
N:     <policy user="root">
N:       <allow ... />
N:     </policy>
N:
N:   which are commonly used for the "agent" pattern seen in services like
N:   BlueZ and NetworkManager: a root-privileged daemon calls out to one or
N:   more per-user user interface agent processes with no specific name, so
N:   send_destination is not easily applicable. However, such rules should
N:   still be made as specific as possible to avoid undesired side-effects.
N:
N:   Please refer to https://bugs.freedesktop.org/show_bug.cgi?id=18961 and
N:   http://lists.freedesktop.org/archives/dbus/2008-February/009401.html for
N:   details.
N:
N:   Visibility: warning
N:   Show-Always: no
N:   Check: desktop/dbus

How could that be improved?
I have no clue how that stuff works.

Andreas