[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 ???)


Reply to: