ngd 510 new stuff

[Luca Boccassi]

On Sat, 2022-02-05 at 13:15 +0100, Andreas Beckmann wrote:
> 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?

Hi,

No idea, sorry - I don't follow the CUDA stuff closely.

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

Yeah it seems very much a WIP service. The bus name doesn't follow the
reverse FQDN convention, and the policy is wide open - at the very
least it would need a user/group, and run the service with that.

But as far as I understand it is not intended to be used yet, and it's
for some vendors to test, and it is not installed by the upstream
installer:

https://forums.developer.nvidia.com/t/510-39-01-beta-driver-nvidia-powerd-causing-high-system-load/200839/6

So the right thing should be to ignore it, for now.

If they ship it as-is in a future release, then I can work out a
sensible policy and drop-ins to reduce privileges.

I have pushed some commits to the 510-preview branch on Salsa that fix
the build of the latest 510 release, as I've tested it on my bookworm
desktop and it seems to run fine. In general when you see I've pushed
an update to a Salsa branch, please assume it means I've tested it on
my system.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-nvidia-devel/attachments/20220205/442bb572/attachment.sig>