Zenaan Harkness <[EMAIL PROTECTED]> writes: > For the benefit of those not versed in deep kernel issues wrt audio > apps, and the benefit of documenting this (very briefly) on debian-mm > list, can you please summarize very briefly these issues/ tradeoffs. By > doing so, we can hopefully understand better the requirements wrt > packaging audio software for Debian...
Not sure what's relevant and what people already know. Nor do I seem able to be brief. ;-) System Security Policy ---------------------- Each system's security admin needs to make policy decisions about what kinds of security risks are acceptable and which are not. Systems differ greatly in this respect. The sysadmin of a high-volume Internet-attached server will be very risk-averse. Such systems rarely run audio applications, but they need to be protected against someone accidentally installing one with inappropriate privileges. For a standalone single-user music workstation (if there still is such a thing), the user may not be terribly concerned about such matters. Running everything as root may even be acceptable. Most real systems fit somewhere between these two extremes. My home development machine is a music workstation, but also has an Internet presence with a fixed IP address running `sendmail', `apache' and `named' servers. I wish I had a spare machine so I could separate those two roles, but I don't. When making security policy, possible attacks ought to be considered and weighed against the costs and benefits of countering them. My main concern is file system and network integrity. I don't want an outside attacker to highjack my mail daemon and use it to send millions of spam messages, or overwrite the web site for my band. I am much less concerned about "denial of service" attacks. If someone with a local login on my system accidentally or intentionally crashes the machine, I will be unhappy but not heart-broken. I can fix it by rebooting. There is no permanent damage. It is trivial for an audio application with realtime privileges to crash a system. On a uni-processor machine, one realtime thread going into a loop will lock the system up solid. I do it to myself sometimes, testing a buggy new version of JACK. On a high-volume server that would be unacceptable, but for me it's merely annoying. Linux Kernel Capabilities ------------------------- This brings us to `capabilities' (not a very good name IMHO). The Linux kernel implements a draft proposal for a POSIX standard that never became a standard. The basic idea was good, dividing the monolithic `root' privilege into smaller capabilities that can be granted to processes (or threads) as needed. This follows the "least privilege principle" discussed earlier. Most of the internal work to support this is present in 2.4. That is, the system calls check `if (capable(CAP_SYS_NICE))' instead of the old Unix `if (suser())'. This allows an audio program to set realtime scheduling (CAP_SYS_NICE), but still access the filesystem without any special authority (CAP_DAC_OVERRIDE would override discretionary access controls, such as the file mode bits and Access Control Lists). IIRC, the original POSIX proposal had a filesystem component, which was never implemented in Linux. Each file had a privilege vector associated with it. At exec() time, the process would inherit those privileges, a kind of fine-grained setuid concept. Its been a long time, and I'm not sure of the details. Since the Linux kernel supports many filesystems, getting them all to allocate space for this privilege vector and support new interfaces for setting and querying them must have been impractical, I suppose. There are also questions about how difficult this would be to administer. Most of us have trouble keeping track of a few mode bits for each file. And, administration is crucial for system security. Many security holes are the result of some admin error. So instead, someone invented CAP_SETPCAP, the capability of bestowing capabilities to another process. This was not in the original POSIX proposal, and it seems to have introduced levels of complexity that were difficult to analyze. At some point the kernel developers seem to have decided that it was too risky for general use. I'm not sure what hole they discovered, but one can imagine an intruder taking over some daemon using a buffer overflow attack, then creating other processes and assigning privileges to them. I don't know. So, they shipped the 2.4 kernel without CAP_SETPCAP included in the privilege set for the init process. This made it impossible for other processes to ever inherit that capability, closing whatever security hole had been deemed too risky. But, this is the essential capability that `jackstart' needs for bestowing realtime capabilities to the JACK server and its clients. The so-called "capabilities patch" merely restores CAP_SETPCAP to the privilege set of `init' and makes them all inheritable by the children of init. Every other process is descended from `init'. This is all JMHO. A lot is second-hand, some of it is probably wrong. Anyone deeply involved in Linux kernel development during the last several years can probably provide a clearer explanation. All I know with any confidence is that from an application perspective, the current interface is almost (but not quite) unusable. If we had the original POSIX scheme of privilege vectors associated with each exec image, I think we could manage it. Debian would install jackd and various other audio applications with just the capabilities they need for realtime processing. An admin concerned about denial of service attacks would choose not to install these programs or would revoke the capabilities from their files. > If I understand correctly, Linux 2.6 has capabilities patch included in > mainline, thus eliminating this as a problem. Since it also includes > lowlatency and preemption patches, we can simply have a "task" package > or such that depends on kernel >= 2.6.0 or something. I have not yet run 2.6 myself. From comments posted on linux-audio-dev I doubt it will solve all the problems. The 2.6 developers claim much better latency results than vanilla 2.4. This is an important step forward, but their claims are still noticeably worse than a properly patched and tuned 2.4 system. IIRC, the differences were very much in the range that low-latency audio cares about (1 to 4 msec). I had not heard about the capabilities patch being included in 2.6. I hope it is. Of course capabilities were also "included" in 2.4, they just disabled the CAP_SETPCAP ability, making them relatively useless. Time for me to download a copy, build and install 2.6. Anyone have a recommendation for running it on a Debian woody system (plus some sarge packages)? Is there a backport site? > > At any rate, this is all much safer than running large amounts of > > untrusted audio code as root. The "least privilege principle" of > > system security states that a program should be delegated no more > > privileges than needed to do its job. > > And should drop any privileges as soon as no longer needed. Sure, although in practice there's not much opportunity for jackd to drop privileges. It tends to keep needing them for starting and stopping realtime operations. We do try to drop privileges for the clients as soon as possible, but I have reason to doubt that this completely works. > > Since we cannot assume the universal existence of group `audio', the > > JACK `make install' sets jackd to root.root 0555 and jackstart to > > root.root 04555. This is only done if the install is running as root > > and JACK was built using --enable-capabilities. > > On Debian there is an audio group, and so Debian packages should install > using it. Isn't it possible to manually check this though, for > non-Debian "make install"? Of course it's not much of a problem for Debian packages, though I suppose they should still check that the group is defined. JACK's make install could do something similar, I suppose. No one ever asked for that before. What is the right way to test for the existence of a group? The obvious hack seems more than a bit kludgy... if grep '^audio:' /etc/group >/dev/null 2>&1; then ... Regards, -- Jack O'Quin Austin, Texas
