[linux-audio-dev] {draft} setgid problems with GTK for realtime audio (long)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [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 - 06:05:53 EET


  {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_AT_music.columbia.edu [2] http://jackit.sourceforge.net [3] http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt [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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Dec 12 2003 - 06:12:18 EET