[linux-audio-dev] Linux Security Module for realtime audio

[Jack O'Quin]

torbenh at gmx.de writes:

> On Tue, Dec 02, 2003 at 11:03:29AM -0600, Jack O'Quin wrote:
> > That's pretty much what I have in mind.  I'm still trying to figure
> > out how to pass the group id as a parameter somewhere.  I wanted to
> > use /proc/sys/kernel/realtime-group, but that seems to require
> > patching the kernel.  It looks like the new sysfs is intended for this
> > purpose.  I'll investigate.
> 
> there are functions to register inodes in proc.
> but i dont consider this necessary. Why would i want to change the
> realtime gid once the module is loaded ?
> 
> modprobe jackcapabilities rtgid=407
> 
> seems sufficient to me...
> and this requires 2 lines of code... see attachement..

Thanks.  I figured there was a way to do that, but had not yet
discovered how.

The desire for a /proc interface was mainly driven by a desire to make
an interface that would be user-space compatible between 2.4 and 2.6,
without requiring 2.4 users to apply that massive selinux patch to
enable LSM support on 2.4.  Maybe there's another solution.  It
probably doesn't *have* to be compatible.  I'll be happy to just get
something that works.

One thing that does seem important is having a really simple way to
shut down the whole mechanism.  Unloading the LSM works, but is
probably not convenient for a server system admin looking to quickly
audit all his systems to make sure they don't have these realtime
capabilities enabled.  Checking that kernel/realtime is 0 seems good
from this perspective.

> considering the configurability of the max frequency fernando posted,
> we need to investigate on mlockall now...

Right.  I still have not seen any code in mlockall() that actually
checks CAP_SYS_RESOURCE.  But, he and I both tried running jackstart
without it an found that mlockall() failed (with EPERM, IIRC).

> > Can you add a new capability without patching the kernel?
> 
> definitely yes...
> capable can be overridden in an LSM.
> but we can still use the current implementation, because capable( i )
> tests if bit i is set in the effective_caps.
> 
> the highest capability number is 28.. so we have 3 caps left.

Ouch!  We'll run out of those in a hurry.  :-)
-- 
  joq