Subject: Re: [linux-audio-dev] Linux Security Module for realtime audio
From: Jack O'Quin (joq_AT_io.com)
Date: Wed Dec 03 2003 - 21:02:26 EET
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
This archive was generated by hypermail 2b28 : Wed Dec 03 2003 - 21:06:31 EET