12 Dec
2003
12 Dec
'03
12:58 p.m.
Tim Janik <timj(a)gtk.org> writes:
That was mentioned in the previous paragraph...
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
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. > 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.