Subject: Re: [linux-audio-dev] {draft} setgid problems with GTK for realtime audio (long)
From: Jack O'Quin (joq_AT_io.com)
Date: Fri Dec 12 2003 - 18:56:17 EET
Tim Janik <timj_AT_gtk.org> writes:
> > Unfortunately, audio applications using GTK cannot take full advantage
> > of this option, because GTK refuses to run setgid. The unintended
> > consequence of that policy is to *increase* our security exposure by
> > forcing us to grant realtime privileges to all the programs of users
> > who need them, when we would prefer to restrict access to just the
> > audio programs, themselves.
>
> this fails to say why the gid checks bound to the GUI are of
> concern for the audio processing stuff at all.
That was mentioned in the previous paragraph...
> > Ideally, our applications would be setgid to that group, so only
> > realtime programs would gain access to these privileges.
> (i.e. why couldn't you simply spawna priviledged audio process,
> drop priviledges and then advance with gtk_init()?)
I guess the real question is: "why don't we just rewrite all these
audio applications?". Do you think we really need to address that?
Perhaps so. The GTK position seems to be that you can only use their
library if you follow certain rules of their devising. This is naive,
but I think they genuinely feel that way. Mostly, I suspect that they
don't want to do the work to make their code secure. But, we're
really not asking them to do that, beyond the reasonable efforts to
fix obvious holes which they say they will do anyway.
> > So, no matter what tests you make, on some modern systems you will
> > not be able to detect when GTK is running in a privileged context.
> >
> > System security is evolving in directions that are outside the scope
> > of GTK and cannot adequately be enforced by any user-level library.
> > Despite good intentions, incomplete security checking tends only to
> > make matters worse.
>
> gtk doesn't mean to enforce any kind of restrictions for user-level
> programs. the rationale is rather: the gtk code can't possibly be
> secured enough to run at elevated priviledges, so the _gtk code_ refuses
> to run at elevated priviledge levels at all.
If refusing to run with any privileges is their goal, then they have
failed completely. We do it all the time right now using JACK
capabilities, which bypasses their checks entirely, or by running as
root with `sudo' or `su'.
This is the heart of their problem. GTK *cannot tell* when it is
running at elevated priviledge levels. It does not detect privilege
levels at all, but merely disallows two of the 17 possible ways of
gaining privilege. By disallowing the mechanism but not the privilege
their action becomes counter-productive, forcing people to use cruder
mechanisms than would otherwise be necessary to acquire the privileges
they need.
I think the sentences quoted above stated this point briefly, but
perhaps a longer explanation is needed?
Thanks for your comments,
-- joq
This archive was generated by hypermail 2b28 : Fri Dec 12 2003 - 18:59:40 EET