[linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Fernando Pablo Lopez-Lezcano]

On Sun, 2003-11-16 at 08:02, Paul Davis wrote:
> >> I've been thinking about ways to use this feature to improve and
> >> simplify the current security situation for Linux audio.  No
> >> conclusions, but here are some thoughts for discussion:
> >>
> >>   (1) There should a simple way for the sysadmin to reliably disallow
>    [ .. ]
> >>   (2) Using sysctl, set a group id (like `audio') for which realtime
>     [ ... ]
> >>   (3) We could also define a default realtime group (gid 0 maybe),
> 
> >What about this one:
> >
> >(4) Let the user that is currently physical logged in to the machine
> >get realtime privileges.
> 
> i'd be interested to hear from fernando about this kind of thing. many
> of us on LAD work on what are to all effects and purposes single user
> machines. i'd like to hear how policies like 1-4 above, or others,
> appear in the context of an academic "shared resource" environment.

["academic" is probably irrelevant, a commercial studio should see the
advantages of the security model if educated]

As far as I understand these are the current options:

a) capabilities
b) simple sysctl patch to the kernel (like the one that Kjetil posted)
c) security module, with possible additional control through sysctl

"b" is better than "a" (more general purpose)
is "b" riskier than "a"?
  you could say yes: all programs can use realtime caps
  you could say no: "a" enables additional unneeded and dangerous stuff
"c" is the same as "b" (from the point of view of a user or sysadmin)
"c" has more long term potential in the sense that it uses a recognized
kernel interface to security (but only on 2.6, right?)

I would be happy with "b" right now. A group would not be important in
_my_ setup, all my users are "audio users", all users can hang the
machine (I have too much to do to try to start categorizing users :-)

I would say (as in Kjetil's patch):
  echo "0">/proc/sys/kernel/setschedandmlock
  --> normal behavior

  echo "1">/proc/sys/kernel/setschedandmlock
  --> access to mlock and SCHED_FIFO and:
     echo "xx">/proc/sys/kernel/setschedandmlockgroup
     --> only users in group "xx" can access privileges
     default for "xx" would be "0" which means everybody

as to (4), it could be useful but I doubt you can easily determine from
inside the kernel that a user is "local" (just guessing). 

> ps. this is the kind of thing that can really distinguish *nix from
> other systems. i've heard from at least academic music department
> about the problems they've faced since being forced to switch to
> windows. 

I would not want to be in that position... 
-- Fernando