Subject: Re: [linux-audio-dev] {draft} setgid problems with GTK for realtime audio (long)
From: Jens M Andreasen (jens.andreasen_AT_chello.se)
Date: Fri Dec 12 2003 - 10:06:49 EET
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
This archive was generated by hypermail 2b28 : Fri Dec 12 2003 - 10:03:56 EET