linux-kernel - Re: [PATCH 4/4] media: uvcvideo: Introduce allow_privacy

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]

Message-ID: <20251119010156.GD23711@pendragon.ideasonboard.com>
Date: Wed, 19 Nov 2025 13:19:55 +0900
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Gergo Koteles <soyer@....hu>, Hans de Goede <hansg@...nel.org>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org
Subject: Re: [PATCH 4/4] media: uvcvideo: Introduce allow_privacy_override

On Tue, Nov 18, 2025 at 10:25:42AM +0100, Ricardo Ribalda wrote:
> On Tue, 18 Nov 2025 at 09:48, Gergo Koteles wrote:
> > On Tue, 2025-11-18 at 07:21 +0100, Ricardo Ribalda wrote:
> > >
> > > Most users expect that the led is always on when the camera is active.
> > > I think the usecases where the led should not be turned on are spooky
> > > or very limited.
> >
> > Or do most users expect that if a piece of hardware has a setting, they
> > can set it without module parameters?
> 
> A piece of hardware that has a non-standard, undocumented setting.
> 
> Do you have a compelling use-case for turning off the privacy LED?

The use case that Logitech added this XU control to support is avoiding
the reflection of the privacy LED in users' glasses.

> > > Even if you use open-source software, when it parses user generated
> > > data, there is a risk for bugs. If there is a bug the only thing
> > > protecting the security of the camera is the membership of the video
> > > group which is a very low barrier.

In modern systems the answer to this would be pipewire and portals (or
similar solutions for vendor operating systems). We'll still need time
until the user won't have direct access to the video device nodes
though.

> > > And once you manage to change the
> > > LED behaviour will persist in other unrelated apps.

Maybe that's something we want to address, and make the control
per-file-handle ?

> > So this is about what if an attacker accessed my passwords, private
> > keys, OTP tokens, emails, pictures and then couldn't take a fresh
> > picture of me in the dark without an LED? I'm smart as hell and I use a
> > privacy tape anyway ;)
> 
> My core goal is simple: if the camera is in use, the privacy LED must
> be ON. If the LED is ON unexpectedly, it serves as a clear indication
> that something unusual is happening.
> 
> Gaining access to the video node does not automatically grant access
> to sensitive data like browser information; there are sandboxes in
> place for that. Also open source does not equate to secure or
> non-malicious code.
> 
> > I think freedom is worth more than this kind of fear.
> 
> No freedom is lost. This change simply increases the
> trustworthiness/reliability of your device.
> 
> On ChromeOS, I don't use a privacy tape, but that's because I know how
> the LED is wired :). I want to achieve a similar level of
> trust/reliability for everyone else.

I'd argue that a privacy tape is useful on those devices too. Far more
common than attack scenarios are cases when you unvoluntarily turn your
webcam on during a call. This is however beside the point.

> In other words, I want to know if someone has seen me without t-shirt,
> eating ice-cream and crying while I am re-watching Coco.

-- 
Regards,

Laurent Pinchart