[alsa-devel] Avoiding wordexp prevents environment variables being used

[Takashi Iwai]

On Fri, 13 Apr 2018 13:58:56 +0200,
Mark Hills wrote:
> 
> On Mon, 9 Apr 2018, Takashi Iwai wrote:
> 
> > On Sun, 08 Apr 2018 18:13:43 +0200,
> > Mark Hills wrote:
> > > 
> > > I just came up against the patch below; it prevents useful snippets of 
> > > alsa-conf like this:
> > > 
> > >   @hooks [
> > >       {
> > >           func load
> > >           files [
> > >               "~/.asoundrc-$HOSTNAME"
> > >           ]
> > >           errors false
> > >        }
> > >   ]
> > > 
> > > as the evalutation of all but "~" has been removed.
> > > 
> > > Seems like removal of a perfectly good feature in the name of security; 
> > > because wordexp()
> > > 
> > > 1) is not used (and should not be used) on data originating from an 
> > >    untrusted source
> > > 
> > > 2) is already used with WRDE_NOCMD, which the same POSIX spec documents 
> > >    as:
> > > 
> > >     "The WRDE_NOCMD flag is provided for applications that, for security 
> > >      or other reasons, want to prevent a user from executing shell 
> > >      commands."
> > > 
> > > 3) on glibc can be seen (with strace) not to execute other commands 
> > > 
> > > If one is to treat the POSIX doc as gospel (as cited by the patch) the 
> > > cause of firefox (circa July 2017) not working would actually be that musl 
> > > does not honour WRDE_NOCMD to the letter. I agree the spec of wordexp() 
> > > could be more useful, though.
> > > 
> > > Also, hypothesising the attacks of an already-compromised application 
> > > would get into a sticky conversation about the thread safety of 
> > > getenv("HOME") (and associated buffer wrangling)  vs. a library function 
> > > being used for its intended purpose.
> > > 
> > > In practice, Firefox may have moved on here (no ALSA support anymore) so 
> > > should quirks of its sandbox be driving this?
> > 
> > What's wrong with you building the alsa-lib with --with-wordexp if you
> > prefer having that behavior?
> 
> Practically, I must build custom packages for all machines (some I do not 
> control, eg. my employer's)
> 
> My case here is both that the default behaviour should not have changed; 
> and that the security rationale offered here is misleading.

How can you assure you'll never hit a badly written wordexp() in the
wild old binary?


Takashi