12 Dec
2003
12 Dec
'03
1:49 a.m.
not meaning to start the actual discussion here, but to point out the
more or less obvious contr points.
On 11 Dec 2003, Jack O'Quin wrote:
Problems with GTK
=================
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.
(i.e. why couldn't you simply spawna priviledged audio process,
drop priviledges and then advance with gtk_init()?)
Requested Change
================
While sympathetic with the concerns and intentions expressed in Owen's
document, we are not happy with the actual implementation. We want
gtk_init() to stop checking that the group ID equals the effective
group ID. If you really feel that some such test is necessary, then
please disallow operation only when the effective gid is zero (`root'
or `wheel' in most systems).
Note that testing for specific user and group privileges does not
conform to current POSIX thinking on the subject. The standard has
adopted the term "appropriate privileges"[8] for describing the
effects of the implementation-defined security mechanism. This was
done to encourage adoption of more granular privilege implementations
than the traditional monolithic Unix superuser approach. 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.
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.
Despite good intentions, incomplete security checking
tends only to
make matters worse.
Regards,
--
Jack O'Quin
Austin, Texas
[1] mailto:linux-audio-dev@music.columbia.edu
[2] http://jackit.sourceforge.net
[3] http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq…
[4] http://archives.neohapsis.com/archives/sendmail/2000-q2/0002.html
[5] http://lsm.immunix.org
[6] http://www.joq.us/realtime/README
[7] http://www.gtk.org/setuid.html
[8] http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap03.html
---
ciaoTJ