linux-kernel - Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 8 May 2024 06:46:53 +0100
From: Daniel Stone <daniel@...ishbar.org>
To: Hans de Goede <hdegoede@...hat.com>, Maxime Ripard <mripard@...hat.com>, 
	Sumit Semwal <sumit.semwal@...aro.org>, 
	Benjamin Gaignard <benjamin.gaignard@...labora.com>, Brian Starkey <Brian.Starkey@....com>, 
	John Stultz <jstultz@...gle.com>, "T.J. Mercier" <tjmercier@...gle.com>, 
	Christian König <christian.koenig@....com>, 
	Lennart Poettering <mzxreary@...inter.de>, Robert Mader <robert.mader@...labora.com>, 
	Sebastien Bacher <sebastien.bacher@...onical.com>, 
	Linux Media Mailing List <linux-media@...r.kernel.org>, 
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, linaro-mm-sig@...ts.linaro.org, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	"Bryan O'Donoghue" <bryan.odonoghue@...aro.org>, Milan Zamazal <mzamazal@...hat.com>, 
	Andrey Konovalov <andrey.konovalov.ynk@...il.com>
Subject: Re: Safety of opening up /dev/dma_heap/* to physically present users
 (udev uaccess tag) ?

Hi,

On Tue, 7 May 2024 at 12:15, Daniel Vetter <daniel@...ll.ch> wrote:
> On Mon, May 06, 2024 at 04:01:42PM +0200, Hans de Goede wrote:
> > On 5/6/24 3:38 PM, Daniel Vetter wrote:
> > I agree that bad applications are an issue, but not for the flathub / snaps
> > case. Flatpacks / snaps run sandboxed and don't have access to a full /dev
> > so those should not be able to open /dev/dma_heap/* independent of
> > the ACLs on /dev/dma_heap/*. The plan is for cameras using the
> > libcamera software ISP to always be accessed through pipewire and
> > the camera portal, so in this case pipewere is taking the place of
> > the compositor in your kms vs render node example.
>
> Yeah essentially if you clarify to "set the permissions such that pipewire
> can do allocations", then I think that makes sense. And is at the same
> level as e.g. drm kms giving compsitors (but _only_ compositors) special
> access rights.

That would have the unfortunate side effect of making sandboxed apps
less efficient on some platforms, since they wouldn't be able to do
direct scanout anymore ...

Cheers,
Daniel