[alsa-devel] Exclusive access to capture device

[Sean McNamara]

On Sun, Jun 24, 2012 at 4:48 PM, Guy Rutenberg <guyrutenberg at gmail.com> wrote:
> Hi Sean,
>
> On Sun, Jun 24, 2012 at 11:31 PM, Sean McNamara <smcnam at gmail.com> wrote:
>>
>>
>> Hopefully you aren't writing a desktop application, because distros
>> and users generally abhor the notion of an application "hogging" the
>> sound device for any reason, and would prefer that all access be
>> non-exclusive. But if you're coding for an embedded device, then I can
>> understand this approach.
>>
>> I'm actually writing a desktop application. The idea is to extract random
> bits from microphone in order to create a true random number generator
> (after being extracted the bits go through an unbiasing phase and
> compression by a hash function to increase entropy). So I intentionally
> want to hog the sound device, as to be sure that nobody else is recording
> at the same time I'm gathering entropy.
>
> So basically I want to temporarily disable any hardware/software mixing on
> the mixing device. Is it possible given user privileges? Assuming
> root privileges?

Anything is possible with root privileges. You could run `fuser' or
`lsof' and find all the processes accessing /dev/snd/* and SIGKILL
them, and then do your capture. You could parse /etc/asound.conf and
figure out whether the default sound device is a software mixer or
pointing to a hardware device by detecting strings like "hw:0". You
could detect the hardware being used and refuse to operate if the user
is running a card with hardware mixing. You can do a lot of really
nasty, imho stupid things.

In the general case of running general hardware on a general desktop
Linux distribution, I would really strongly advise you NOT to attempt
to reconfigure the user's sound system, kill daemons or applications,
or otherwise "hog" the sound device, unless you are only doing this
"in-house" on systems you have full control over. I can guarantee you
that users will take significant beef with your program if you try to
distribute your software to the general public.

Besides, ALSA is open source, so someone could effectively counter
your attempts in an infinite number of ways, by writing their own
modified libasound that lies to you and makes you *think* you have
exclusive access when you really don't. Ditto for the kernel.

There is no way to absolutely *prevent* an untrusted system from doing
anything. If the *user* of the system has root, and you're just a
program, guarantees are meaningless. They could have a custom
filesystem that makes you think that /dev/snd/* are hardware ALSA
devices, but are in fact just CUSE devices from the kernel, feeding
you a pre-determined stream of integers.

Sounds like you're trying to do something with DRM or randomly
generating crypto certificates or something. Use an interface that's
more reliable and draw from /dev/urandom or something -- ALSA is not
designed to be part of a security system. Even if there were a
parameter to snd_pcm_open() that let you explicitly ask for exclusive
access, all bets are off if you don't trust every single bit of
executable code on the system.

This is why I said "if you are on an embedded platform" then this
would make sense, because embedded developers typically control
everything from the hardware up. But even then, every single Android
device to market has been rooted so far, so....

If you're looking for good sources of entropy, look at the code that
OpenSSL uses for generating RSA private keys. It's still not
completely airtight because, like I said, any "external" sources that
you rely on for entropy could easily be preempted by the user or a
virus to feed you pre-determined sequences of numbers; but OpenSSL
does it pretty good to the extent that the user and their software
stack are not trying to fool you on purpose.

Good luck,

Sean

>
> Thanks,
>
> Guy
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel