Re: Audio Apps Mini-Policy, v0.1
On Tue, 2003-10-28 at 22:47, Steve Kemp wrote:
> On Tue, Oct 28, 2003 at 09:43:07PM +1100, Zenaan Harkness wrote:
>
> > 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"??]
> > - user = read, write, execute
> > - group = read, execute
> > - other = read only
>
> Why read only for other? Given that they can't execute what is
> presumably a compiled binary I'd treat them as untrusted and not allow
> them to read it at all.
>
> So:
>
> user : rwx
> group: rx
> other:
By my reading of policy, the idea with read access for other is that by
removing read capability, all we are doing is forcing them to go
download/ extract the package manually, which is simply an
inconvenience, not an increase or decrease of security. Thus, read
access might as well be granted.
> > 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?
>
> I think that the SGID would be fine if it were just a matter of
> reading/writing audio devices. However in the case of tools that need
> realtime priority you'll need SUID to do this. If you're SUID already
> then being SGID(audio) is redundent.
Ahh - this might be the core of the two concepts being mixed (by my lack
of understanding) - I believe that jackd doesn't necessarily talk to any
audio device, it is simply about scheduling priority. Thus jackstart the
wrapper. So perhaps our "generic suid/ capability wrapper" would be:
- jack the wrapper, or jtw
of course, then we'd have to come up with an expansion/ meaning of "jack"
outside of the audio domain (JACK - A Capability Killer ? :)
I think I'm understanding the two concepts here as
1) audio device access - require user to have audio group privs
2) realtime scheduling requirements - use capabilities, ala jackstart
(But this requires a custom kernel ???)
ta
zen
Reply to: