[Adding linux-audio-dev to the CC list] Matt Mackall <mpm(a)selenic.com> writes: The answer to your simple question is a long, sad story. :-( There is clearly no practical way to write large audio applications (many with elaborate graphical interfaces) securly enough to run them as root. So, we have used capabilities with linux-2.4 systems for several years. It was never a satisfactory solution, but was all we could do at the time. There is a small setuid program called `jackstart' that exec()s the JACK server (`jackd') with appropriate privileges so it can pass realtime privileges to its applications. Each client needs to create a realtime thread and mlock() its storage to do its part of the realtime audio cycle. Note that sched_setschedule() provides no way to handle the mlock() requirement, which cannot be done from another process. Clients may come and go at any time, so dropping the privilege after initialization is not an option. Unfortunately, all this heavyweight mechanism only helps with JACK and its many clients. Lots of other audio or video oriented applications also have realtime needs. The biggest problem was CAP_SETPCAP, which for good reasons[1] is disabled in distributed kernels. This forced every user to patch and build a custom kernel. Worse, it opened all our systems up to the problems reported by this sendmail security advisory. [1] http://www.securiteam.com/unixfocus/5KQ040A1RI.html While stumbling along with this very unsatisfactory state of affairs, many on the Linux Audio Developers mailing list were shocked[2] to hear about an LKML discussion[3] suggesting a significant lack of developer committment to addressing these issues... [2] http://www.music.columbia.edu/pipermail/linux-audio-dev/2003-November/00533… [3] http://www.kerneltraffic.org/kernel-traffic/kt20031101_239.html#3 So, all our work, frustration and user confusion while trying to "do the right thing" seemed doomed to failure. Since the Linux kernel developers continued to show little interest in our needs, we started a discussion about how to meet them ourselves[4]. [4] http://www.music.columbia.edu/pipermail/linux-audio-dev/2003-November/00534… Looking at our security requirements in a practical manner, we quickly concluded that CAP_SETPCAP is the work of the devil. A true filesystem-based privilege vector solution might be adequate, but is clearly beyond the scope of what we audio programmers could hope to accomplish. Even then, it would be difficult to administer. A simple group ID test is far more secure than CAP_SETPCAP, and perfectly adequate for us. When configuring a Digital Audio Workstation, one is not terribly concerned about local Denial of Service attacks or runaway realtime threads. That would be unacceptable for many other systems, but not ours. Yet, we want to avoid system integrity holes in network daemons like sendmail[1]. In other words: we can tolerate the bad guys crashing the system, but we don't want them turning it into an open spam relay or corrupting the filesystem. So, we needed to provide a simple way for an unskilled system admin (aka "musician") to configure a personal workstation to run realtime applications without opening egregious security holes. Equally important, it must be easy for other system admins to ensure that these privileges are *not* available on their server systems. It soon became apparent that the then-new LSM framework provided a good solution. Because LSM's can be built outside the kernel source tree, we were no longer forced to wait for some kernel developer to take an interest. The realtime-lsm is the solution we evolved. It has been actively used by thousands of Linux audio users for over a year now[5]. The first supported SourceForge release was in April of 2004[6]. It is now used by many popular audio-oriented distributions, including Planet CCRMA[7] from Stanford University and the Debian Music Distribution[8] from the AGNULA project. [5] http://www.music.columbia.edu/pipermail/linux-audio-dev/2003-December/00574… [6] http://eca.cx/laa/2004/04/0028.html [7] http://ccrma.stanford.edu/planetccrma/software/ [8] http://www.agnula.org/ I understand that kernel developers are busy and have other problems they consider more important than ours. But, you ought to at least understand that this is really important to us. We needed a clean solution two or three years ago. Now we finally have one. Distributing it with the kernel sources would be a great convenience for our users and would significantly simplify maintenance. It would also (IMHO) close a significant security and usability deficiency in the standard kernel. Any of the NSA and DoD experts will tell you: a security solution that is difficult to administer is not secure. It is no surprise that kernel developers should consider our solution technically inferior to their own ideas on the subject. I would have been delighted to have some kernel developer step in and provide a clean, well-thought out solution several years ago. This is a kernel deficiency, not an audio problem. I don't want to work on kernels. But, I am feeling quite discouraged that so many kernel developers still seem to consider this problem unimportant. I sense a distinct unwillingness to move forward on this issue. I really hope I am wrong about that. -- joq