nia
If the webcam is attached via an xhci bus (USB 3), it will have that behaviour.
Yes, this seems to be the case according to usbdevs. This is an in-built webcam so I can't change the connectivity unfortunately. Regardless, as per my edit, no panic after the reboot: it works just right.
For hdaudio devices the microphone generating input will depend on the currently selected ADC. e.g. to use my laptop's internal mic, I have:
I am using your aiomixer to play with the sources and such. I have both a USB microphone and an inbuilt one: I see no additional source when I plug the microphone in (it's a snowball). Regardless of source chosen, I don't get any response from programs (e.g. firefox) nor from audiorecord. I also don't see any source being muted. I can see that mixerctl record.source updates as per aiomixer (as expected).
There's various ways to get something approximating FDE (honestly, that term annoys me... at best it's always partial).
Ultimately, rather than FDE (the means), what matters is the goal: avoiding unauthorized 3rd parties from peeking at the data while the device is turned off (if it's on, all bets are off anyway).
As you surely know, the basic rationale is that:
Unencrypted boot opens the way to evil maid attacks (but not much else, unless more than the bootsystem is exposed on the unencrypted disk). Unencrypted swap is more worrying if the user likes suspend to disk. Additionally, it can also be used in combination with other attacks to push pages into swap to be read by the attacker later. This has also previously been exploited to overwrite swapped-out pages to get arbitrary code execution as the page is restored. The point is that simply encrypted the disk of interest is of limited use in a vacuum, as the unencrypted disks defeat it.
Finally, in practice, all of this is rather unusual concerns except in very peculiar circumstances, or by policy requirements (arguably except the unencrypted swap as untrusted peripherals could leverage this in practice).
Perhaps veriexec is sufficient to defeat evil-maid attacks, and perhaps swap can safely live in the same encrypted device. If so, there is no difference in outcome as far as I know.
In the end, the reason I'm exploring this angle out of interest is that SED (sufficiently encrypted disk, since you don't like FDE) is very easy to setup on, say, linux (well, there are caveats to this notion of 'easy'...) and becomes "free security from volcanoes" -- the user is hardly impacted, beside having to enter a password, connect a device that contains a keyfile, or similar (the performance impact is negligible for almost all use-cases where SED is typically considered), and gains safety from a rare but possibly highly damaging event. SED is therefore usually the favored solution, but it doesn't matter what specific solution does achieve the goal of this setup.
Thus, another way to phrase the question is: what's a good setup to achieve data protection from unauthorized 3rd parties at rest?
You could also do it the oldshool way, with chroot...
Is there documentation somewhere about this?
Thank you for your response.
