Re: fw: jackd/ audio apps mini policy
Zenaan Harkness <zen@iptaustralia.net> 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
Reply to: