Re: Audio Apps Mini-Policy, v0.1

[Matt Zimmerman <mdz@debian.org>]

On Tue, Oct 28, 2003 at 09:43:07PM +1100, Zenaan Harkness wrote:

> This is a follow up to the jackd/ dpkg-statoverride thread, and a
> request for comment on the below. Once informally vetted here, I will
> post to debiam-multimedia.
> 
> Input appreciated
> Zen
> 
> ---
> Title: Audio Apps Mini Policy
> Authors: Zenaan Harkness
> Version: 0.1
> Date: 2003-10-28
> 
> Applicability: Audio apps requiring realtime scheduling (or other root)
> privileges to operate effectively.
> 
> Policy:
> Audio applications or applets (ie. executable files) requiring realtime
> privileges should be installed as follows:
>  - user = root
>  - group = audio
>  - permissions
>    - SUID root
>      - have a debconf question asking to allow/ deny this
>      - [debconf question "importance level"??]

       - application must _completely_ relinquish root privileges
	 _immediately_ after obtaining the CAP_SYS_NICE capability
	 (if you aren't sure, ASK)

I'm actually starting to wonder whether we should have a general facility
for these sorts of things.  Having apps be setuid root and expecting them to
behave responsibility is asking for trouble; it would make much more sense
to grant them only the capability that they need.  I don't know whether
there is a filesystem extension to grant capabilities to binaries, but we
probably couldn't rely on it anyway.  We _could_ implement a setuid root
wrapper which would read a configuration file listing which binaries should
be granted what capabilities, with relative ease.

> Anyone, how does Andreas' comment "We _do_ have an audio-group and users
> who need to have access to /dev/{mixer,snd,dsp,..} should be put in there,
> instead of making the app SGID." apply here - ie. am I confused about the
> use of SUID?

This is something different.  For applications which require access to the
sound device, they should have no setid permissions and expect that the user
already has permission to access the device through their group membership.

> Another comment I received, this time about capabilities, was the
> following (there is the JACK (jackd) audio daemon, and "jackstart" program
> to run it): "With jackstart. you can run jackd and it's clients as
> non-root user - only jackstart has to be setuid root, jackd need not.
> This has the advantage that files recorded with a jack client like ardour
> aren't owned by root, for example."

This is a similar idea to the wrapper I described above, though it probably
works quite differently (maybe even specific to jack).

-- 
 - mdz