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: <b55a513fb25c47411ab7289f3812187e3f67da43.camel@irl.hu>
Date: Tue, 18 Nov 2025 12:14:11 +0100
From: Gergo Koteles <soyer@....hu>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
  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

Hi Ricardo,

On Tue, 2025-11-18 at 10:25 +0100, Ricardo Ribalda wrote:
> Hi Gergo
> 
> On Tue, 18 Nov 2025 at 09:48, Gergo Koteles <soyer@....hu> wrote:
> > 
> > Hi Ricardo,
> > 
> > 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?
> 

As a pet camera, it is useful to be able to turn off the LED.
In some cases, it can also eliminate unwanted reflections.
Some cameras may have blue LED, and if someone hates blue LEDs..

> > 
> > > 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. And once you manage to change the
> > > LED behaviour will persist in other unrelated apps.
> > > 
> > 
> > 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.
> 

Applications that access a video node usually have multiple permissions
(at least on my system). But I understand there may be cases where they
only have access to a video node and then this can be useful.

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

It will decrease to the extent that fewer people will know that such an
option exists because they will not read the description of the
module's parameters.

And people won't even know that it can be turned off as root, and even
a curl | sudo... installation can take a picture of them without an
LED.

And it's not possible to be sure that there isn't another undocumented
option in the firmware to turn it off the LED.

A physical switch would be the best for this control, but that's not an
option :(



Gergo