12 Dec
2003
12 Dec
'03
12:07 a.m.
{This is a draft of a note for the GTK developers, requesting them
to soften their position on disallowing setgid. Please post
comments and suggestions. It carries more weight coming from a
group of us. Also, please tell me where this is should go.}
{The note seems overly long. Suggestions for things to leave out?
Perhaps I should post some of this on the web as a white paper, and
send them a much shorter message pointing to it.}
Rationale
=========
A number of us in the Linux Audio Developers community[1] are trying
to come up with practical ways of dealing with the security exposures
inherent in realtime audio. Our problem is that many audio
applications require realtime scheduling and memory locking privileges
to achieve stable, low-latency performance.
While not a direct threat to system integrity, these privileges easily
allow anyone with a local login to accidentally or intentionally
freeze the machine. In security jargon, this is known as "Denial of
Service". For a dedicated Digital Audio Workstation system, the risk
is generally acceptable. But, we want to do our best to minimize its
effects.
Historically, many Linux audio applications required users to login as
root when needing realtime privileges. Large audio programs often
include complex graphical user interfaces, digital signal processing,
and multi-threaded buffer handling. Running all this as root leaves
the system wide open to devastating security attacks. This is what we
want to avoid.
Solutions Considered
====================
Some packages, like the JACK Audio Connection Kit[2], have
successfully used Linux kernel capabilities[3] to run realtime audio
applications using an ordinary user ID with only the necessary
permissions delegated. Unfortunately, the Linux kernel developers do
not fully support this, because that mechanism currently has known
security holes[4]. Consequently, kernels are shipped with it partly
disabled. The 2.4 kernel requires users to make a two-line patch,
then recompile and reinstall to enable this feature.
As these problems are not likely to be resolved any time soon, we have
been investigating other solutions. The 2.6 kernels provide a new
Linux Security Module (LSM) mechanism[5]. With that, we can turn on
capabilities without forcing all our users to patch their kernels.
But, the security exposure in the capabilities mechanism remains.
So, we are working on an experimental LSM for 2.6 that grants realtime
privileges to applications based on several optional criteria[6]. The
most secure option only grants realtime access to programs or users
belonging to a specific group ID, such as `realtime' or `audio'.
Ideally, our applications would be setgid to that group, so only
realtime programs would gain access to these privileges.
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.
We have read with interest the rationale[7] given by Owen Taylor of
the GTK development team for disallowing the use of setuid and setgid
in GTK applications.
Owen writes:
In the opinion of the GTK+ team, the only correct way to write a
setuid program with a graphical user interface is to have a setuid
backend that communicates with the non-setuid graphical user
interface via a mechanism such as a pipe and that considers the
input it receives to be untrusted.
This is a fine suggestion, and certainly one viable approach. But, it
seems presumptuous to claim that it is the "only correct way". One
cannot force the many existing Linux audio applications to be
rewritten to follow this advice, and it is unclear that there is any
good reason to do so. Since GUI threads generally use non-privileged
scheduling, in practice realtime priority is restricted to the I/O and
signal processing threads anyway.
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.
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
12 Dec
12 Dec
1:29 a.m.
It needs some nice ending.
We respectfully ask that you reconsider the implementation of this check.
Or something
2: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
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.
2:30 p.m.
On Fri, Dec 12, 2003 at 10:56:17AM -0600, Jack O'Quin wrote:
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.
Those might be lightened a bit, but they might go well into your letter.
3:26 p.m.
On Fri, Dec 12, 2003 at 10:56:17AM -0600, Jack
O'Quin wrote:
indeed, because these are the core of the issue.
whether or not we should write our RT audio apps as two processes
connected by a pipe/socket - thats a long philosophical argument on
which reasonable people can agree to differ and may even take
different positions according to the details of a given situation.
whether or not (a) the current check prevents GTK+ code from running with
elevated priviledges, and (b) whether it interferes with more "graceful"
techniques for gaining such priviledge: these are simply matters of
fact: (a) it does not, and (b) it does.
i would shorten down the letter and focus on this issue.
--p
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.
Those might be lightened a bit, but they might go well into your letter. 
4:08 a.m.
New subject: [linux-audio-dev] {draft} setgid problems with GTK for realtime audio (long)
Hi Jack!
I am in a very bad mood today, so I thought that it would be good for
you if I did some critisiscm of this draft.
Good news: No "Hallelujas"
Bad news: I might go over the top?
Nothing is personal. I just try to think from the perspective of the
gtk-team.
cheers // Jens M Andreasen
On Fri, 2003-12-12 at 05:05, Jack O'Quin wrote:
-<snip>
Rationale
=========
A number of us in the Linux Audio Developers community[1] are trying
to come up with practical ways of dealing with the security exposures
inherent in realtime audio. Our problem is that many audio
applications require realtime scheduling and memory locking privileges
to achieve stable, low-latency performance.
While not a direct threat to system integrity, these privileges easily
allow anyone with a local login to accidentally or intentionally
freeze the machine. In security jargon, this is known as "Denial of
Service". For a dedicated Digital Audio Workstation system, the risk
is generally acceptable. But, we want to do our best to minimize its
effects.
Historically, many Linux audio applications required users to login as
root when needing realtime privileges. ...
Ehrm .. Historically users of realtime audio needed to chmod (as root)
their trusted audio applictions 4711. Those applications that did not
switch back to normal untrusted lu^H^H user couldn't enjoy the
gratification of a graphic (gtk) interface ...
...... Large audio
programs often
include complex graphical user interfaces, digital signal processing,
and multi-threaded buffer handling. Running all this as root leaves
the system wide open to devastating security attacks. This is what we
want to avoid.
Seems like a good idea not to do that (see above)
Solutions Considered
====================
You forgot to mention a *real* problem? Or a goal?
You want to have dynamic realtime threads? OK, then launch a bunch of
idle threads and assign them a task (or an array of tasks) when your
application has figured out what it is, it is supposed to do.
You want to lock some memory? Fine, do that, and then launch gtk! Oh,
you maybe want some more later. Sorry, your other applications grabbed
what they needed head on!
Some packages, like the JACK Audio Connection Kit[2], have
successfully used Linux kernel capabilities[3] to run realtime audio
applications using an ordinary user ID with only the necessary
permissions delegated. Unfortunately, the Linux kernel developers do
not fully support this, because that mechanism currently has known
security holes[4]. Consequently, kernels are shipped with it partly
disabled. The 2.4 kernel requires users to make a two-line patch,
then recompile and reinstall to enable this feature.
As these problems are not likely to be resolved any time soon, we have
been investigating other solutions. The 2.6 kernels provide a new
Linux Security Module (LSM) mechanism[5]. With that, we can turn on
capabilities without forcing all our users to patch their kernels.
But, the security exposure in the capabilities mechanism remains.
So, we are working on an experimental LSM for 2.6 that grants realtime
privileges to applications based on several optional criteria[6]. The
most secure option only grants realtime access to programs or users
belonging to a specific group ID, such as `realtime' or `audio'.
Ideally, our applications would be setgid to that group, so only
realtime programs would gain access to these privileges.
If you managed to fsck up your machine as root, how will it improve the
situation of affairs when your boy/girlfriend can do it too?
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 is posible today (see above) Gtk is a pseudoproblem.
We have read with interest the rationale[7] given by
Owen Taylor of
the GTK development team for disallowing the use of setuid and setgid
in GTK applications.
Owen writes:
In the opinion of the GTK+ team, the only correct way to write a
setuid program with a graphical user interface is to have a setuid
backend that communicates with the non-setuid graphical user
interface via a mechanism such as a pipe and that considers the
input it receives to be untrusted.
It is also mentioned that gtk is heavily depended on X, which is heavily
depended on other external libraries which the gtk team do not/will
not/have no idea how to deal with.
This is a fine suggestion, and certainly one viable
approach. But, it
seems presumptuous to claim that it is the "only correct way". One
cannot force the many existing Linux audio applications to be
rewritten to follow this advice, and it is unclear that there is any
good reason to do so. Since GUI threads generally use non-privileged
scheduling, in practice realtime priority is restricted to the I/O and
signal processing threads anyway.
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.
Posix has no "thinking" regarding WIMPs
............ 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.
Despite good intentions, incomplete security checking tends only to
make matters worse.
Regards,
"Ehrm, howto say?" -Dalai Lama
2:59 p.m.
Jens M Andreasen <jens.andreasen(a)chello.se> writes:
Why?
Remind me what WIMPs stands for, so I can understand this comment.
Thanks for your comments,
--
joq
I am in a very bad mood today, so I thought that it
would be good for
you if I did some critisiscm of this draft.
Good. Every project needs a curmudgeon. ;-)
On Fri, 2003-12-12 at 05:05, Jack O'Quin wrote:
This is not true for any of the ones I am aware of (such as ardour,
ecasound, alsaplayer, qjackctl, jamin, etc.). IIRC, the thinking has
been that it is better to force users to demonstrate that they already
have root authority (via `login' or `sudo' or `su') than to grant root
privileges to obviously insecure programs.
To me, this makes sense. Users who already have root access can do as
much damage as they want, anyway. Running an audio application
doesn't make this exposure that much worse, except insofar as the
application itself may be a trojan horse or be tricked into loading
bogus code as a plugin, or writing a file it shouldn't have, etc., all
good reasons to avoid running *anything* as root.
JACK may seem like an exception, since `jackstart' *is* installed
setuid root. But, this is done to bestow realtime capabilities on
`jackd' and all its clients. In that situation, GTK is already
running with the realtime privileges we want, but doesn't realize it.
Perhaps there *are* some audio applications that install themselves
setuid root in the way you suggest. Could you name a few?
MUSE is the only other setuid root program in my /usr/local/bin.
Perhaps it works that way? I am unfamiliar with its internals, though
I see it uses QT, and not GTK.
Historically, many Linux audio applications
required users to login as
root when needing realtime privileges. ...
Ehrm .. Historically users of realtime audio needed to chmod (as root)
their trusted audio applictions 4711. Those applications that did not
switch back to normal untrusted lu^H^H user couldn't enjoy the
gratification of a graphic (gtk) interface ... You forgot to mention a *real* problem? Or a goal?
I did, but perhaps you didn't accept it. :-)
You want to have dynamic realtime threads? OK, then
launch a bunch of
idle threads and assign them a task (or an array of tasks) when your
application has figured out what it is, it is supposed to do.
You want to lock some memory? Fine, do that, and then launch gtk! Oh,
you maybe want some more later. Sorry, your other applications grabbed
what they needed head on!
These fall under the general question: "why don't you people just
rewrite all your audio applications the way we say they should have
been done?" I'm sure variations of this question will arise.
As long as one deals purely with hypothetical and not real programs,
they are unanswerable in the abstract. There is nothing wrong with
running the GUI in a separate process as they suggest, except that it
is quite difficult to retrofit into an existing application.
Plus, there is always the painful, but clearly doable, option of
converting everything to QT, instead. It's all just an SMOP (Simple
Matter of Programming). :-)
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 is posible today (see above) Gtk is a pseudoproblem. It is also mentioned that gtk is heavily depended on
X, which is heavily
depended on other external libraries which the gtk team do not/will
not/have no idea how to deal with.
I don't think anyone is asking them to take responsibility for things
that are outside their control. We should state that explicitly.
But, that is the point really. They should not take responsibility
for telling us how to do realtime audio, either.
Note that
testing for specific user and group privileges does not
conform to current POSIX thinking on the subject.
Posix has no "thinking" regarding WIMPs 
7680
days inactive
7681
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
6 participants
participants (6)
-
Jack O'Quin -
Jens M Andreasen -
Jesper Anderson -
Paul Davis -
Tim Hockin -
Tim Janik