Re: [linux-audio-dev] Linux Security Module for realtime audio
On Wed, 2003-12-10 at 21:24, Benno Senoner wrote: > -- > So in conclusion I'd say: don't run your disk butlers SCHED_FIFO/RR but > use nice(-10) or something alike. > Same for GUIs if you care about reaction speed of the GUI run it > nice(-10) because with nice you don't risk hogging > the machine because of a slow gfx card/drivers or because of a > suboptimal redrawing implementation. > Now that I have moved up from gtk to gtk2, I can follow your advice :) > cheers, > Benno cheers // Jens M Andreasen
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Thu, Dec 11, 2003 at 09:15:50AM -0600, Jack O'Quin wrote:
> I've been looking at that, and plan to do it next. A good example is
> always helpful. It can help to avoid missing some subtle detail,
> especially important for kernel-mode programming.
Here is some of the boilerplate code we used. Also have code to make a proc
dir and use it, so instead of /proc/realtime or what not, you could have
/proc/realtime/a, /proc/realtime/b, etc. Also have code to do a read/write
proc file.
These are against linux-2.4. Haven't played with proc on 2.6, yet.
#include
#ifdef CONFIG_PROC_FS
static struct proc_dir_entry *proc_foo;
#endif
init(...)
{
...
#ifdef CONFIG_PROC_FS
proc_foo = create_proc_read_entry("foo", 0, NULL, foo_read_proc, NULL);
if (!proc_foo {
printk(KERN_ERR "can't create /proc/foo\n");
}
#endif
...
}
cleanup(...)
{
...
remove_proc_entry("foo", NULL);
...
}
#ifdef CONFIG_PROC_FS
static int
foo_read_proc(char *buf, char **start, off_t pos, int len, int *eof, void *x)
{
int plen;
plen = sprintf(buf, "%s\n", foo);
/* trying to read a bad offset? */
if (pos >= plen) {
*eof = 1;
return 0;
}
/* did we write everything we wanted to? */
if (len >= (plen-pos)) {
*eof = 1;
}
*start = buf + pos;
plen -= pos;
return (len > plen) ? plen : len;
}
#endif
Re: [linux-audio-dev] Linux Security Module for realtime audio
[EMAIL PROTECTED] writes: > i talked to tim janik on #lad yesterday and he said, that we should mail > gtk-devel-list and CC: owen taylor with a description of the problem, > and with a statement that we have read setuid.html. > > what we need is, that the test must be for [ug]id == 0 and not generally > uid != e_uid. > > so we have a chance of getting this into gtk. > > joq: You are a native speaker, can you write the mail ? I only speak Texan, not English, but I'll be happy to compose a note. I'll post a draft here first, so y'all can critique it. ;-) -- joq
Re: [linux-audio-dev] Linux Security Module for realtime audio
[EMAIL PROTECTED] writes: > setting up a proc readable file is not so hard. Tim Hockin <[EMAIL PROTECTED]> writes: > making a proc file is trivial, really. I have lots of example code > for simple proc file interfaces (read and write). Need it? I've been looking at that, and plan to do it next. A good example is always helpful. It can help to avoid missing some subtle detail, especially important for kernel-mode programming. > but we could also printk it on module load. > > but then it will become more complicated: > > dmesg | grep "Realtime Security:" | tail -n 1 The realtime-0.0.2 I posted yesterday already lists its options using printk. For those who wish to look at it, I put a copy on my home system... http://www.joq.us/realtime/realtime-0.0.2.tar.gz -- joq
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Wed, Dec 10, 2003 at 09:11:44PM -0800, Tim Hockin wrote: > On Thu, Dec 11, 2003 at 10:00:16AM +0100, [EMAIL PROTECTED] wrote: > > > But, I don't know how to query the module parameters, and that would > > > certainly be useful. > > > > setting up a proc readable file is not so hard. > > making a proc file is trivial, really. I have lots of example code for > simple proc file interfaces (read and write). Need it? well there seems to be enough in the kernel itself... but anyway: yes please.. > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Thu, Dec 11, 2003 at 10:00:16AM +0100, [EMAIL PROTECTED] wrote: > > But, I don't know how to query the module parameters, and that would > > certainly be useful. > > setting up a proc readable file is not so hard. making a proc file is trivial, really. I have lots of example code for simple proc file interfaces (read and write). Need it?
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Tue, Dec 09, 2003 at 01:05:51PM -0600, Jack O'Quin wrote: > Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> writes: > > > > thats why i dont consider it necessary. what do you need the proc entry > > > for fernando ? > > > > Just asking, I guess it is not really needed, just unloading and loading > > should be enough. It would be nice to have some sort of confirmation > > from /proc that the module is there and which options are active. Maybe > > that information is available somewhere after the module is loaded. > > These are valid concerns. It's not hard to detect that the module is > loaded, `lsmod | grep realtime' works. > > But, I don't know how to query the module parameters, and that would > certainly be useful. setting up a proc readable file is not so hard. but we could also printk it on module load. but then it will become more complicated: dmesg | grep "Realtime Security:" | tail -n 1 > -- > joq > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Tue, Dec 09, 2003 at 01:38:44AM +0100, Jesper Anderson wrote: > On Mon, Dec 08, 2003 at 12:13:48PM -0800, Tim Hockin wrote: > > On Tue, Dec 09, 2003 at 12:49:24AM +0100, Jesper Anderson wrote: > > > GTK has been like that for years now. Check the archives of SLASH'EM, > > > a Nethack clone, for lots of back and forth. In short, they're not > > > going to change. > > > > Do they have a valid reason? Or are they just imposing their paranoia on us > > for fun? > > Their explanation is here: > > http://www.gtk.org/setuid.html > > They've met a lot of resistance and not backed down yet; I seriously > doubt they will. Therefore, coding around it in a consistent way will > be necessary. I'll dig in my archives and see what I can find ... > although I'm not sure an of it is useful. i talked to tim janik on #lad yesterday and he said, that we should mail gtk-devel-list and CC: owen taylor with a description of the problem, and with a statement that we have read setuid.html. what we need is, that the test must be for [ug]id == 0 and not generally uid != e_uid. so we have a chance of getting this into gtk. joq: You are a native speaker, can you write the mail ? -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Wed, 2003-12-10 at 15:45, Paul Davis wrote: > >Updating 120 GTK+ sliders (as a consequence of a patch change) took > >several seconds before I made the gtk thread SCHED_RR. I would call that > >a missed visual deadline, No? > > no, i'd call it an error in the toolkit or your own code. i have no > idea which. what version of GTK+ are you using, and are they regular > GTK+ sliders? > The sluggish behaviour was with GTK-1.2 I have reasently changed to GTK-2.2 and pulled out my attempts at working around some of the shortcomings in 1.2 (slider values were upside down, mousewheel moved in the wrong direction) So I tried just now to take away SCHED_RR in the GUI. It works reasonably well. Problem solved :) cheers // Jens M Andreasen
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Wed, 10 Dec 2003 09:45:16 -0500, Paul Davis wrote > >Updating 120 GTK+ sliders (as a consequence of a patch change) took > >several seconds before I made the gtk thread SCHED_RR. I would call that > >a missed visual deadline, No? > > no, i'd call it an error in the toolkit or your own code. i have no > idea which. what version of GTK+ are you using, and are they regular > GTK+ sliders? I've seen behaviour like that occasionally when I've got too many places in GUI code that's waiting to get a lock on data from the audio. I think I was redrawing sliders from values being sent back from the audio thread and basically calling one blocking mutex per slider. It can get very slow (but is quite easy to fix...) dave . www.pawfal.org/nebogeo
Re: [linux-audio-dev] Linux Security Module for realtime audio
>Updating 120 GTK+ sliders (as a consequence of a patch change) took >several seconds before I made the gtk thread SCHED_RR. I would call that >a missed visual deadline, No? no, i'd call it an error in the toolkit or your own code. i have no idea which. what version of GTK+ are you using, and are they regular GTK+ sliders?
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Wed, 2003-12-10 at 13:20, Paul Davis wrote: > look, there are only 60-80 *physical* redraws of a monitor screen per > second. you have, therefore, *at least* 1/100 of a second before > you've "missed" a "graphics deadline". not only that, but because of > the properties of the human visual system, missing the deadline won't > matter in anything like the way missing an audio deadline does. this > has none of the characteristics of "real time" from my perspective. > Updating 120 GTK+ sliders (as a consequence of a patch change) took several seconds before I made the gtk thread SCHED_RR. I would call that a missed visual deadline, No? Notice that this sluggish behaviour is when the audio engine is near idle, just writing silence to my ISA soundcard, which shows up as system is using 5% cpu, user 0.1% cpu. Now it takes a guesstimate of 0.3 seconds, perhaps a little less. The kernel (and scheduler) is from the latest Mandrake 9.2 distribution and I haven't yet found any notes on what patches they have applied this time ... > now, if the audio thread is burning so much CPU time that the GUI > doesn't get to run, its certainly a problem. but step back - is it a > problem you want to fix by raising the priority of the GUI thread so > that it steals time from the audio thread? No and the gui doesn't steal any noticeable time. I use something like: gui_priority = audio_priority/20; If I am maxing out the number of running voices then there will be nearly no graphic updates at all (which is as it happens also the desired behaviour.) cheers // Jens M Andreasen
Re: [linux-audio-dev] Linux Security Module for realtime audio
Paul Davis wrote: now, if the audio thread is burning so much CPU time that the GUI doesn't get to run, its certainly a problem. but step back - is it a problem you want to fix by raising the priority of the GUI thread so that it steals time from the audio thread? or even from a "disk butler" thread. no, i don't think so. it simply means that the user is asking too much from their current hardware (and/or that the s/w is badly implemented, but thats a different story). Speaking about the disk butler thread, I don't know what kind of priority ardour's one uses but in LinuxSampler we experienced weird behaviour when running the disk thread with SCHED_FIFO/RR , even at low priorities. The problem is the following: normally the disk thread calls read() to read data from disk and since read() must wait for the disk I/O subsystems it often relinquishes the CPU and thus is causing no problems to the other active processes. But since in LinuxSampler we often hit a situation where most of the initial parts of each sample (that is streamed from disk) gets cached by the linux disk i/o layer it means that the read() call will very often read from the cache (thus doing a memory copy) instead from disk. This is good because it avoids many unnecessary disk accesses (otherwise we would need to write our own caching algorithm but since Linux works so well we used the kernel's one). But there is a weird side effect that arises when the disk thread runs with real time priority. Assume a not so fast CPU (with relatively low RAM bandwidth), when you play many notes at the same time where most of the streams are cached (because your RAM is large enough to cache most of the samples needed) then the disk thread will issue read()s that will almost everytime translate to memory copying (from the disk cache to the userspace buffer). This means a substantial chunk of CPU is used (eg 20-30%) by the disk thread to copy the data. And since the disk thread is optimized to read() large segments from disk in order to maximize bandwidth, it could happen that it read()s let's say 100 (# of voices) x 200KB of data = 20MB before going to sleep. This could stall the machine for several dozen/hundreds msecs stalling GUIs and making the overall usage of the machine sluggish. This is why I now run the diskthread without real time privileges because if the above situation happens it does not suck away precious CPU time (the disk thread always tries to refill all ringbuffers until they are completely full but that is not strictly needed) making the box unresponsive. So in conclusion I'd say: don't run your disk butlers SCHED_FIFO/RR but use nice(-10) or something alike. Same for GUIs if you care about reaction speed of the GUI run it nice(-10) because with nice you don't risk hogging the machine because of a slow gfx card/drivers or because of a suboptimal redrawing implementation. cheers, Benno http://www.linuxsampler.org
Re: [linux-audio-dev] Linux Security Module for realtime audio
>> And I see no reason why drawing a colorful GUI should require realtime >> privileges -- it's the other way round: the audio processing should >> have priority over the GUI. >> > >If the GUI is not running in realtime, then things like changing the >patch number from the midi stream won't be reflected instantaniously on >screen. To the contrary: You can almost imagine SuperMario running up >and down the interface with his little brushes, slowly repainting each >and every knob and slider :-) This happens even if the realtime audio >engine is near idle. > >The audio engine can still have priority over the GUI. That is to say: >The GUI is another realtime process albeit with a much lower priority >(than the audio engine.) i think this is sort of absurd. yes, technically its true but "much lower priority" means "so much lower" that talking about the GUI as though its RT doesn't make any sense. look, there are only 60-80 *physical* redraws of a monitor screen per second. you have, therefore, *at least* 1/100 of a second before you've "missed" a "graphics deadline". not only that, but because of the properties of the human visual system, missing the deadline won't matter in anything like the way missing an audio deadline does. this has none of the characteristics of "real time" from my perspective. now, if the audio thread is burning so much CPU time that the GUI doesn't get to run, its certainly a problem. but step back - is it a problem you want to fix by raising the priority of the GUI thread so that it steals time from the audio thread? or even from a "disk butler" thread. no, i don't think so. it simply means that the user is asking too much from their current hardware (and/or that the s/w is badly implemented, but thats a different story). do you want the GUI thread to have higher priority than cron? sure. but if cron running is causing super mario to be a little sluggish, you've got deeper problems to solve first. --p
Re: [linux-audio-dev] Linux Security Module for realtime audio
Jens M Andreasen wrote: If the GUI is not running in realtime, then things like changing the patch number from the midi stream won't be reflected instantaniously on screen. To the contrary: You can almost imagine SuperMario running up and down the interface with his little brushes, slowly repainting each and every knob and slider :-) This happens even if the realtime audio engine is near idle. The audio engine can still have priority over the GUI. That is to say: The GUI is another realtime process albeit with a much lower priority (than the audio engine.) Jens I disagree here: given the slowness of X11 and/or some gfx card/PC combination, if you run the GUI process with real time privileges, you can run into situations where the box becomes unusable because the GUI uses up all the available CPU. (Imagine a sequencer updating dozen of pianorolls, volume peak meters, FFT displays etc, this can easily bring a 2GHz box on its knees). So what I propose is to run the GUI with some negative nice value, eg -10 but not with SCHED_FIFO/RR. Plus if the machine is under high load because the audio thread uses up 90% of the CPU then even running the GUI with real time scheduling won't chane anything, repaints would still be slow. Benno http://www.linuxsampler.org
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Tue, 2003-12-09 at 09:08, Clemens Ladisch wrote: > Jesper Anderson wrote: > > > > Their explanation is here: > > > > http://www.gtk.org/setuid.html > > Good reasons, IMHO. > > And I see no reason why drawing a colorful GUI should require realtime > privileges -- it's the other way round: the audio processing should > have priority over the GUI. > If the GUI is not running in realtime, then things like changing the patch number from the midi stream won't be reflected instantaniously on screen. To the contrary: You can almost imagine SuperMario running up and down the interface with his little brushes, slowly repainting each and every knob and slider :-) This happens even if the realtime audio engine is near idle. The audio engine can still have priority over the GUI. That is to say: The GUI is another realtime process albeit with a much lower priority (than the audio engine.) cheers // Jens M Andreasen > Seperating the audio engine and the GUI into different processes is > the unixy way anyway. > > > Regards, > Clemens > >
Re: [linux-audio-dev] Linux Security Module for realtime audio
Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> writes: > > thats why i dont consider it necessary. what do you need the proc entry > > for fernando ? > > Just asking, I guess it is not really needed, just unloading and loading > should be enough. It would be nice to have some sort of confirmation > from /proc that the module is there and which options are active. Maybe > that information is available somewhere after the module is loaded. These are valid concerns. It's not hard to detect that the module is loaded, `lsmod | grep realtime' works. But, I don't know how to query the module parameters, and that would certainly be useful. -- joq
Re: [linux-audio-dev] Linux Security Module for realtime audio
> > The load time access is not so bad. You can rmmod and then reload the > > LSM if you want to change its parameters. I've been doing that a lot > > for testing. This has no effect on processes that are already > > running. > > thats why i dont consider it necessary. what do you need the proc entry > for fernando ? Just asking, I guess it is not really needed, just unloading and loading should be enough. It would be nice to have some sort of confirmation from /proc that the module is there and which options are active. Maybe that information is available somewhere after the module is loaded. -- Fernando
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Mon, Dec 08, 2003 at 10:38:59PM -0600, Jack O'Quin wrote: > Not right now. I haven't discovered a way to add an entry to /proc > without patching the kernel, and I don't want to do that. There is a > new `sysfs' in 2.6 that seems to allow similar kinds of dynamic > control. I haven't figured out how to use that yet. patching is not necessary. look at /usr/src/linux/include/linux/proc_fs.h there are the functions for creating a proc entry. should be some 10 lines of code including handling the string to int conversion. > > The load time access is not so bad. You can rmmod and then reload the > LSM if you want to change its parameters. I've been doing that a lot > for testing. This has no effect on processes that are already > running. thats why i dont consider it necessary. what do you need the proc entry for fernando ? the question is, if we want to backport the functionality to 2.4... then we would need the proc entry in the 2.6 module also for consistency. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Mon, Dec 08, 2003 at 05:12:50PM -0600, Jack O'Quin wrote: > [EMAIL PROTECTED] writes: > > hmm... perhaps we trick the binary by setting the gid back > > to the e_gid after enabling capabilities :) > > Clever idea, but contrary to the POSIX standard for exec()... > > [explanation why not so clever :] i knew it was an evil hack didnt think about the problems it would introduce (which you state down there). so i guess we should that in the application. > Among other things, this would cause the process to have the wrong > file system access authority. For example, Debian defines a group > `audio' which has access to the sound devices. It would be natural to > grant this group realtime privileges, but with your hack such programs > would lose access to those devices (unless the user also belongs to > group `audio'). oh right... i didnt think of making apps setgid audio to access the audio device, because this is normally done by pam which chowns the audio device to the user logged into the console. but we should not confuse admins with hacky behaviour. > If you accept my arguments why this is not the right solution, then i accept them (although i like hacks :) > the question remains, what to do about GTK-2? I don't suppose the GTK later in thread it seems clear that it wont be taken out. so we shall stay pragmatic. but we could try to convinve tim janik of BEAST, who is also a gtk core dev, to make it test for [gu]id == 0 > > Is there some reasonable way to work around it? There is the obvious > application-level hack of resetting the gid to the real value and then > restoring it to the saved value around the call to gtk_init(). I > consider this unworkable in practice, since it would have to be done > in *every* realtime application using GTK. Without wholesale changes > of this nature our realtime group LSM approach becomes relatively > useless. but these changes are trivial and can be patched in by the distro, to make it work, and if me and fernando post the patches upstream it should get into new versions quite fast. > > > So, I modified Torben's LSM to check supplementary groups, and this > > > seems to work fine. From a system admin perspective it's pretty good. > > > I'm a member of group `audio', which was accomplished by adding my > > > user ID (joq) to the appropriate entry in /etc/group... > > > > > > [...] > > > > well this is an alternative but i would be happier to explicitely give > > away the DOS privilege to programs. rather than enabling it for my > > account. > > I completely agree that my supplementary groups idea is less secure > than the setgid approach. I was just trying to find *something* that > would actually work. I didn't think of your e_gid hack above, which I > admire though I do not accept it. Maybe we can come up with another, > better idea. But checking the groups is necessary for good behaviour. still puzzeled... > > > For reasons I cannot explain, this works without requiring the > > > CAP_SYS_RESOURCE capability, a welcome but unexpected bonus. > > > > very nice indeed. i really wasnt very happy with RESOURCE > > I wasn't either. Unfortunately, for reasons I still cannot explain > (but see below) it now seems to be needed. hmmm... then we have to look at the codepath and see where and why its needed. > > It is possible that I just failed to notice earlier that mlockall() > had failed. The symptoms of that failure are much more subtle than > failure to gain SCHED_FIFO privileges. Unless the system is heavily > loaded, the needed pages rarely get paged out. So, things may appear > to run correctly for quite a while. > > In fact, I recommend making the mlockall() capabilities optional. For > casual use, it will often be acceptable to run without them. good... > > > > I would appreciate comments, feedback, and bug reports. If you want > > > to try it, don't forget that it has received minimal testing. Neither > > > I nor anyone else can promise that it will not adversely affect your > > > system security or stability. Caveat emptor! > > A recent thread on [EMAIL PROTECTED] underscores this > point... > >Subject: PROBLEM: A Capability LSM Module serious bug > >Abstract When POSIX Capability LSM module isn't compiled into >kernel, after inserting Capability module into kernel, all existed >normal users processes will have total Capability privileges of >superuser (root). uhh... how does that happen ? i will look at the dummy security... -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Mon, Dec 08, 2003 at 11:38:55AM -0800, Tim Hockin wrote: > Have we tried? It seems like a deeply paramoid check, to disallow sgid > programs. Is that REALLY the business of the toolkit? I think they're > overstepping their bounds, and they need to be reminded that some OTHER > people need stuff like that. I agree. This is definitely *not* any business for a graphical / windowing toolkit. This test should be removed. -- FA
Re: [linux-audio-dev] Linux Security Module for realtime audio
Jesper Anderson wrote: > On Mon, Dec 08, 2003 at 12:13:48PM -0800, Tim Hockin wrote: > > Do they have a valid reason? Or are they just imposing their paranoia on us > > for fun? > > Their explanation is here: > > http://www.gtk.org/setuid.html Good reasons, IMHO. And I see no reason why drawing a colorful GUI should require realtime privileges -- it's the other way round: the audio processing should have priority over the GUI. Seperating the audio engine and the GUI into different processes is the unixy way anyway. Regards, Clemens
Re: [linux-audio-dev] Linux Security Module for realtime audio
Tim Hockin <[EMAIL PROTECTED]> writes: > I apologizer if this has been discussed, but I haven't read the whole > thread. Has the idea of a simple sched_rr helper been discussed? Roger Larsson has an rt_monitor program that can do most of what you suggest. It also limits the fraction of the CPU these threads are allowed to consume. But, it can't handle mlockall(), and that's a show-stopper for some (but not all) serious audio uses. > It can be setuid and only executable by a specific group. > > rtsched my_rt_app > setscheduler > drop privs > exec > > I guess that doesn't help mlockall(), though. Hrrm. Right. And it doesn't help when the program wants to create a realtime thread later, like all JACK and PortAudio applications do. -- joq
Re: [linux-audio-dev] Linux Security Module for realtime audio
Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> writes: > Thanks for the clarification, I was getting confused... so the GTK > problem only happens if you try to tag executables only for realtime > access. Right. GTK complains if its executable uses either setuid or setgid. This is regrettable, because setgid is more secure than assigning a set of users to the group. With setgid it is possible to restrict realtime privileges to a known set of programs. Otherwise, any program the privileged users execute can hang the system. > I'm not yet testing 2.6.0 (well, I just booted it once a couple of > days ago). Is there anything being done for 2.4.x? I'm just fooling around with this stuff in my spare time right now. I made a 2.4.23-rc5 kernel patch to implement the /proc/sys/kernel interfaces we discussed. But, then I decided to check out 2.6 to see what can be done with the new LSM framework. That seems like the more important question. We already have 2.4 solutions via the capabilities patch. I expect a lot of audio users will migrate to 2.6 once it's released (pretty soon). Of course, your decisions and AGNULA's will have a big effect on that. > > # modprobe realtime # `jackstart' capabilities only > > Meaning? This enables capabilities processing, equivalent to the 2.4 kernel capabilities patch. A program with appropriate privileges (including CAP_SETPCAP) can assign realtime privileges to other processes. So, your `jackstart' program works without requiring a kernel patch. > Sounds good to me. Is it possible to control the options through /proc > as well? Or just at load time? Not right now. I haven't discovered a way to add an entry to /proc without patching the kernel, and I don't want to do that. There is a new `sysfs' in 2.6 that seems to allow similar kinds of dynamic control. I haven't figured out how to use that yet. The load time access is not so bad. You can rmmod and then reload the LSM if you want to change its parameters. I've been doing that a lot for testing. This has no effect on processes that are already running. -- joq
Re: [linux-audio-dev] Linux Security Module for realtime audio
I apologizer if this has been discussed, but I haven't read the whole thread. Has the idea of a simple sched_rr helper been discussed? It can be setuid and only executable by a specific group. rtsched my_rt_app setscheduler drop privs exec I guess that doesn't help mlockall(), though. Hrrm.
Re: [linux-audio-dev] Linux Security Module for realtime audio
> > The "sgid approach" is in addition to having a realtime group or > > instead? I have the feeling I have missed something in the thread. > > The setgid approach *is* a match on the realtime group. The question > is which of several group IDs to you actually match against. Torben's > jackcaps-0.2 checked only the effective group ID of the exec file. > > My current version checks others, too: the user's real and > supplementary groups. Note that these are set by login, newgrp, > etc. and are independent of the actual program being loaded. Thanks for the clarification, I was getting confused... so the GTK problem only happens if you try to tag executables only for realtime access. > I'll append a copy to this message, so you can look at it. It's not > ready to release yet. But, it seems to work for me. I'm not yet testing 2.6.0 (well, I just booted it once a couple of days ago). Is there anything being done for 2.4.x? > My current prototype is called `realtime', not `jackcapabilities', and > has the following load-time options.. > > # modprobe realtime # `jackstart' capabilities only Meaning? > # modprobe realtime any=1 # option a) > # modprobe realtime gid=29# options b) and c) > > I plan to to add another option, mlock=0, for people who don't feel > the need for locking storage. With this option, I would only grant > CAP_SYS_NICE. Sounds good to me. Is it possible to control the options through /proc as well? Or just at load time? -- Fernando
Re: [linux-audio-dev] Linux Security Module for realtime audio
Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> writes: > The "sgid approach" is in addition to having a realtime group or > instead? I have the feeling I have missed something in the thread. The setgid approach *is* a match on the realtime group. The question is which of several group IDs to you actually match against. Torben's jackcaps-0.2 checked only the effective group ID of the exec file. My current version checks others, too: the user's real and supplementary groups. Note that these are set by login, newgrp, etc. and are independent of the actual program being loaded. I'll append a copy to this message, so you can look at it. It's not ready to release yet. But, it seems to work for me. > I would prefer to have the option of: > > a) no protection: I turn on "realtime" (/proc control and/or loading the >realtime module, right?) and any user can run any program and crash >the system by hogging the cpu in a tight loop :-) > > b) a group of users: only users in a designated group can crash the >system. > > c) a group of programs: only writers of realtime "approved" programs get >a chance (through the help of any user or users in a group) to crash >the system. > > Most probably in my environment I would use a), maybe b), most probably > not c). My current version supports all of these. The problem we have been discussing today is that option c) does not work for GTK applications. Since this is actually the most secure of the three options, that seems regrettable. I think the GTK developers made a mistake. When dealing with system security they seem to be operating outside their area of expertise. Of course, the same could be said for most of us. ;-) My current prototype is called `realtime', not `jackcapabilities', and has the following load-time options.. # modprobe realtime # `jackstart' capabilities only # modprobe realtime any=1 # option a) # modprobe realtime gid=29# options b) and c) I plan to to add another option, mlock=0, for people who don't feel the need for locking storage. With this option, I would only grant CAP_SYS_NICE. I believe there are cases where this is sufficient. -- joq realtime-0.0.1.tar.gz Description: realtime LSM (preliminary)
Re: [linux-audio-dev] Linux Security Module for realtime audio
> > > So, I modified Torben's LSM to check supplementary groups, and this > > > seems to work fine. From a system admin perspective it's pretty good. > > > I'm a member of group `audio', which was accomplished by adding my > > > user ID (joq) to the appropriate entry in /etc/group... > > > > > > [...] > > > > well this is an alternative but i would be happier to explicitely give > > away the DOS privilege to programs. rather than enabling it for my > > account. > > I completely agree that my supplementary groups idea is less secure > than the setgid approach. The "sgid approach" is in addition to having a realtime group or instead? I have the feeling I have missed something in the thread. I would prefer to have the option of: a) no protection: I turn on "realtime" (/proc control and/or loading the realtime module, right?) and any user can run any program and crash the system by hogging the cpu in a tight loop :-) b) a group of users: only users in a designated group can crash the system. c) a group of programs: only writers of realtime "approved" programs get a chance (through the help of any user or users in a group) to crash the system. Most probably in my environment I would use a), maybe b), most probably not c). -- Fernando
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Mon, Dec 08, 2003 at 12:13:48PM -0800, Tim Hockin wrote: > On Tue, Dec 09, 2003 at 12:49:24AM +0100, Jesper Anderson wrote: > > GTK has been like that for years now. Check the archives of SLASH'EM, > > a Nethack clone, for lots of back and forth. In short, they're not > > going to change. > > Do they have a valid reason? Or are they just imposing their paranoia on us > for fun? Their explanation is here: http://www.gtk.org/setuid.html They've met a lot of resistance and not backed down yet; I seriously doubt they will. Therefore, coding around it in a consistent way will be necessary. I'll dig in my archives and see what I can find ... although I'm not sure an of it is useful. Jesper
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Sun, 2003-12-07 at 01:35, Jack O'Quin wrote:
> I've been experimenting with Torben's LSM for the 2.6 kernel, and the
> realtime group permissions mechanism we discussed.
>
> Naturally, there are some problems. The worst is that GTK-2 will not
> tolerate the use of setgid...
>
> (process:11284): Gtk-WARNING **: This process is currently running setuid or
> setgid.
> This is not a supported use of GTK+. You must create a helper
> program instead. For further details, see:
>
> http://www.gtk.org/setuid.html
>
> Refusing to initialize GTK+.
In order to get the graphic interface snappy and responsive, I start the
following pthread:
void * interface(void* t_arg)
{
struct sched_param schp;
/** We need realtime performance
*
*/
memset(&schp, 0, sizeof(schp));
schp.sched_priority = sched_get_priority_max(SCHED_RR)/20;
printf("InterfacePriority level: %d\n",schp.sched_priority);
if (sched_setscheduler(0, SCHED_RR, &schp) != 0)
{
perror("sched_setscheduler");
}
else
setreuid(getuid(), getuid());
// This is the call that starts GTK
main_interface(_argc,_argv);
// When we get here, tell everybody else to go home
running = FALSE;
return NULL;
}
mvh // Jens M Andreasen
> This seems to totally invalidate the setgid approach we had discussed,
> at least for audio applications using GTK. QT does not seem to
> complain about setgid, though most of the reasons for avoiding it with
> GTK surely apply there as well.
--
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Tue, Dec 09, 2003 at 12:49:24AM +0100, Jesper Anderson wrote: > GTK has been like that for years now. Check the archives of SLASH'EM, > a Nethack clone, for lots of back and forth. In short, they're not > going to change. Do they have a valid reason? Or are they just imposing their paranoia on us for fun?
Re: [linux-audio-dev] Linux Security Module for realtime audio
Tim Hockin <[EMAIL PROTECTED]> writes: > On Mon, Dec 08, 2003 at 05:12:50PM -0600, Jack O'Quin wrote: > > If you accept my arguments why this is not the right solution, then > > the question remains, what to do about GTK-2? I don't suppose the GTK > > developers are likely to take the test out just because we ask them. > > Have we tried? It seems like a deeply paramoid check, to disallow sgid > programs. Is that REALLY the business of the toolkit? I think they're > overstepping their bounds, and they need to be reminded that some OTHER > people need stuff like that. No. We just discovered the problem ourselves. You make a good point about a dialogue being worthwhile, and we should do that. I am willing to compose a note explaining the problem. What forum would be appropriate? Is there a gtk-devel-something-or-other mailing list? Of course, even if we convince them to change, there will be a considerable lag between fixing their code in CVS and libraries appearing in the binary distributions people use for running audio applications. I'm not even at their latest level of GTK-2. For all I know, they could have fixed it already in some newer version. -- joq
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Mon, Dec 08, 2003 at 11:38:55AM -0800, Tim Hockin wrote: > On Mon, Dec 08, 2003 at 05:12:50PM -0600, Jack O'Quin wrote: > > If you accept my arguments why this is not the right solution, > > then the question remains, what to do about GTK-2? I don't > > suppose the GTK developers are likely to take the test out just > > because we ask them. > > Have we tried? It seems like a deeply paramoid check, to disallow > sgid programs. Is that REALLY the business of the toolkit? I think > they're overstepping their bounds, and they need to be reminded that > some OTHER people need stuff like that. GTK has been like that for years now. Check the archives of SLASH'EM, a Nethack clone, for lots of back and forth. In short, they're not going to change. Jesper
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Mon, Dec 08, 2003 at 05:12:50PM -0600, Jack O'Quin wrote: > If you accept my arguments why this is not the right solution, then > the question remains, what to do about GTK-2? I don't suppose the GTK > developers are likely to take the test out just because we ask them. Have we tried? It seems like a deeply paramoid check, to disallow sgid programs. Is that REALLY the business of the toolkit? I think they're overstepping their bounds, and they need to be reminded that some OTHER people need stuff like that.
Re: [linux-audio-dev] Linux Security Module for realtime audio
> On Sat, Dec 06, 2003 at 06:35:45PM -0600, Jack O'Quin wrote: > > Naturally, there are some problems. The worst is that GTK-2 will not > > tolerate the use of setgid... [EMAIL PROTECTED] writes: > hmm... perhaps we trick the binary by setting the gid back > to the e_gid after enabling capabilities :) Clever idea, but contrary to the POSIX standard for exec()... Similarly, if the set-group-ID mode bit of the new process image file is set, the effective group ID of the new process image shall be set to the group ID of the new process image file. The real user ID, real group ID, and supplementary group IDs of the new process image shall remain the same as those of the calling process image[1]. [1] http://www.opengroup.org/onlinepubs/007904975/functions/exec.html When the standard says "shall be set", it means they're not kidding. :-) Among other things, this would cause the process to have the wrong file system access authority. For example, Debian defines a group `audio' which has access to the sound devices. It would be natural to grant this group realtime privileges, but with your hack such programs would lose access to those devices (unless the user also belongs to group `audio'). If you accept my arguments why this is not the right solution, then the question remains, what to do about GTK-2? I don't suppose the GTK developers are likely to take the test out just because we ask them. In our case, this test has the unintended result of making system security worse rather than better. I personally think their test is wrong-headed except in the case of setuid to root, which may make sense. Is there some reasonable way to work around it? There is the obvious application-level hack of resetting the gid to the real value and then restoring it to the saved value around the call to gtk_init(). I consider this unworkable in practice, since it would have to be done in *every* realtime application using GTK. Without wholesale changes of this nature our realtime group LSM approach becomes relatively useless. > i am not sure what you did to the jack cvs. i hope you dont check > for the realtime group as it wont work anymore :) caps are enabled > silently :) > > but i guess you try to get them and revert to the old mechanisms if > it fails. I just removed an internal test for `has_capabilities', which was getting in the way of a workaround for some problems creating realtime POSIX threads under Linux. I don't think the test was needed in the first place, and it was getting in the way when the needed capabilities are present, but not via `jackstart'. > > So, I modified Torben's LSM to check supplementary groups, and this > > seems to work fine. From a system admin perspective it's pretty good. > > I'm a member of group `audio', which was accomplished by adding my > > user ID (joq) to the appropriate entry in /etc/group... > > > > [...] > > well this is an alternative but i would be happier to explicitely give > away the DOS privilege to programs. rather than enabling it for my > account. I completely agree that my supplementary groups idea is less secure than the setgid approach. I was just trying to find *something* that would actually work. I didn't think of your e_gid hack above, which I admire though I do not accept it. Maybe we can come up with another, better idea. > > For reasons I cannot explain, this works without requiring the > > CAP_SYS_RESOURCE capability, a welcome but unexpected bonus. > > very nice indeed. i really wasnt very happy with RESOURCE I wasn't either. Unfortunately, for reasons I still cannot explain (but see below) it now seems to be needed. It is possible that I just failed to notice earlier that mlockall() had failed. The symptoms of that failure are much more subtle than failure to gain SCHED_FIFO privileges. Unless the system is heavily loaded, the needed pages rarely get paged out. So, things may appear to run correctly for quite a while. In fact, I recommend making the mlockall() capabilities optional. For casual use, it will often be acceptable to run without them. > > I would appreciate comments, feedback, and bug reports. If you want > > to try it, don't forget that it has received minimal testing. Neither > > I nor anyone else can promise that it will not adversely affect your > > system security or stability. Caveat emptor! A recent thread on [EMAIL PROTECTED] underscores this point... Subject: PROBLEM: A Capability LSM Module serious bug Abstract When POSIX Capability LSM module isn't compiled into kernel, after inserting Capability module into kernel, all existed normal users processes will have total Capability privileges of superuser (root). It is possible that this may have contributed to my confusion about whether CAP_SYS_RESOURCE is really needed. Before seeing this message, I was already wondering if there are any free POSIX-compliance test suites available for
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Sat, Dec 06, 2003 at 06:35:45PM -0600, Jack O'Quin wrote:
>
> I've been experimenting with Torben's LSM for the 2.6 kernel, and the
> realtime group permissions mechanism we discussed.
>
> Naturally, there are some problems. The worst is that GTK-2 will not
> tolerate the use of setgid...
uhh... i only tested with muse. now this is really bad.
hmm... perhaps we trick the binary by setting the gid back
to the e_gid after enabling capabilities :)
it works... add this to my version:
if( (rtgid != 0) && (bprm->e_gid == rtgid) ) {
+
+ bprm->e_gid = current->gid;
+
bprm->cap_effective = CAP_TO_MASK(CAP_IPC_LOCK) |
CAP_TO_MASK(CAP_SYS_NICE) | CAP_TO_MASK(CAP_SYS_RESOURCE);
bprm->cap_permitted = CAP_TO_MASK(CAP_IPC_LOCK) |
CAP_TO_MASK(CAP_SYS_NICE) | CAP_TO_MASK(CAP_SYS_RESOURCE);
}
i am not sure what you did to the jack cvs.
i hope you dont check for the realtime group as it wont work anymore :)
caps are enabled silently :)
but i guess you try to get them and revert to the old mechanisms if it fails.
> So, I modified Torben's LSM to check supplementary groups, and this
> seems to work fine. From a system admin perspective it's pretty good.
> I'm a member of group `audio', which was accomplished by adding my
> user ID (joq) to the appropriate entry in /etc/group...
>
> [...]
well this is an alternative but i would be happier to explicitely give
away the DOS privilege to programs. rather than enabling it for my
account.
> For reasons I cannot explain, this works without requiring the
> CAP_SYS_RESOURCE capability, a welcome but unexpected bonus.
very nice indeed. i really wasnt very happy with RESOURCE
> I would appreciate comments, feedback, and bug reports. If you want
> to try it, don't forget that it has received minimal testing. Neither
> I nor anyone else can promise that it will not adversely affect your
> system security or stability. Caveat emptor!
yep...
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Re: [linux-audio-dev] Linux Security Module for realtime audio
>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). did you check glibc?
Re: [linux-audio-dev] Linux Security Module for realtime audio
[EMAIL PROTECTED] 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
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Tue, Dec 02, 2003 at 11:03:29AM -0600, Jack O'Quin wrote:
> [EMAIL PROTECTED] writes:
>
> > the most simple way would be parameters given to the module for the
> > realtime group and user. There are nice macros for module parameters.
> >
> > i believe that adding to the currently overridden function
> >
> > if( bprm->e_gid == realtime_gid ) {
> > bprm->cap_effective = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> > bprm->cap_permitted = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> > }
> >
> > should work fine.
>
> 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..
>
> > although i am not happy with CAP_SYS_RESOURCE ( needed for RTC
> > interrupts > 64Hz ) which also allows a process to Override quota
> > limits.
>
> Agreed. This is sometimes needed but not always. Maybe it should be
> a separate module to use as required.
considering the configurability of the max frequency fernando posted,
we need to investigate on mlockall now...
>
> > But because in drivers/char/rtc.c the check is
> > if ( capable( CAP_SYS_RESOURCE ) ) { allow higher freq }
> >
> > it seems like its not possible with the current implementation.
> > but we could however provide a jackrtc module which checks for a
> > new CAP_RTC_INTS.
>
> 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.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
jackcaps-0.2.tar.gz
Description: application/tar-gz
Re: [linux-audio-dev] Linux Security Module for realtime audio
> > > attached is what i have done today works, but needs to
> > > be checked by someone who can judge about the sideeffects.
> > >
> > > i am not so sure about them.
> >
> > Encouraged by your success, I plan to modify this LSM to implement the
> > `kernel/realtime' and `kernel/realtime-group' interfaces we discussed
> > recently. I'll keep you posted on how that progresses.
>
> the most simple way would be parameters given to the module for the
> realtime group and user. There are nice macros for module parameters.
>
> i believe that adding to the currently overridden function
>
> if( bprm->e_gid == realtime_gid ) {
> bprm->cap_effective = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> bprm->cap_permitted = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> }
>
> should work fine.
>
> although i am not happy with CAP_SYS_RESOURCE ( needed for RTC interrupts > 64Hz )
> which also allows a process to Override quota limits.
This was needed to make mlockall work (on 2.4.x). CAP_IPC_LOCK was not
enough, I don't know why. We tried removing it and memory locking broke.
Is this on 2.6? Maybe it is different.
Re: the rtc clock, in 2.4 there is a /proc/sys/dev/rtc/max-user-freq
control file that can be used to rise the maximum rtc clock frequency a
normal user can set.
> But because in drivers/char/rtc.c the check is
> if ( capable( CAP_SYS_RESOURCE ) ) { allow higher freq }
>
> it seems like its not possible with the current implementation.
> but we could however provide a jackrtc module which checks for a
> new CAP_RTC_INTS.
-- Fernando
Re: [linux-audio-dev] Linux Security Module for realtime audio
[EMAIL PROTECTED] writes:
> the most simple way would be parameters given to the module for the
> realtime group and user. There are nice macros for module parameters.
>
> i believe that adding to the currently overridden function
>
> if( bprm->e_gid == realtime_gid ) {
> bprm->cap_effective = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> bprm->cap_permitted = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> }
>
> should work fine.
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.
> although i am not happy with CAP_SYS_RESOURCE ( needed for RTC
> interrupts > 64Hz ) which also allows a process to Override quota
> limits.
Agreed. This is sometimes needed but not always. Maybe it should be
a separate module to use as required.
> But because in drivers/char/rtc.c the check is
> if ( capable( CAP_SYS_RESOURCE ) ) { allow higher freq }
>
> it seems like its not possible with the current implementation.
> but we could however provide a jackrtc module which checks for a
> new CAP_RTC_INTS.
Can you add a new capability without patching the kernel?
--
joq
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Sun, Nov 30, 2003 at 10:10:45PM -0600, Jack O'Quin wrote:
> [EMAIL PROTECTED] wrote:
>
> > attached is what i have done today works, but needs to
> > be checked by someone who can judge about the sideeffects.
> >
> > i am not so sure about them.
>
> Encouraged by your success, I plan to modify this LSM to implement the
> `kernel/realtime' and `kernel/realtime-group' interfaces we discussed
> recently. I'll keep you posted on how that progresses.
the most simple way would be parameters given to the module for the
realtime group and user. There are nice macros for module parameters.
i believe that adding to the currently overridden function
if( bprm->e_gid == realtime_gid ) {
bprm->cap_effective = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
bprm->cap_permitted = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
}
should work fine.
although i am not happy with CAP_SYS_RESOURCE ( needed for RTC interrupts > 64Hz )
which also allows a process to Override quota limits.
But because in drivers/char/rtc.c the check is
if ( capable( CAP_SYS_RESOURCE ) ) { allow higher freq }
it seems like its not possible with the current implementation.
but we could however provide a jackrtc module which checks for a
new CAP_RTC_INTS.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Re: [linux-audio-dev] Linux Security Module for realtime audio
[EMAIL PROTECTED] wrote: > attached is what i have done today works, but needs to > be checked by someone who can judge about the sideeffects. > > i am not so sure about them. I can't comment on the overall security of your module, Torben. But, I did finally find time to try it out, and it works great. Yesterday, I downloaded linux-2.6.0-test11 from kernel.org, configured it to use ALSA, preemptive scheduling, and LSM with capabilites. I built that and installed it. Everything comes up and runs fine. Then, I built the jackcap LSM you posted here. It compiled and installed in `/lib/modules/2.6.0-test11/extra/jackcapabilities.ko'. After running `modprobe jackcapabilities', `jackstart -R' was working. I am very pleased by how cleanly this all worked. Using the 2.6 preemptive scheduler I can run JACK at -r44100 -p64 (a 1.5msec period) with only occasional xruns. I've seen eight in the last hour. That's under light load. Not good enough for pro audio, but fine for most consumer use, I suspect. And this was using a standard kernel right out of the box. The rest of my system and its hardware are fairly well tuned, of course. Newbies probably won't do as well. Encouraged by your success, I plan to modify this LSM to implement the `kernel/realtime' and `kernel/realtime-group' interfaces we discussed recently. I'll keep you posted on how that progresses. -- joq
Re: [linux-audio-dev] Linux Security Module for realtime audio
[EMAIL PROTECTED] writes: > attached is what i have done today works, but needs to > be checked by someone who can judge about the sideeffects. Cool. Thanks, Torben. Doing it with so little code is encouraging, and speaks well for the modularity of the 2.6 kernel. I looked at your code, but am not completely up to speed on kernel security modules yet. It looks like your module essentially duplicates the effect of the 2.4 "capabilities patch". With this loaded, it will be possible to run the existing `jackstart' exactly as we do today on a capabilities- enabled 2.4 kernel. Is that right? That is wonderful. > i am not so sure about them. I'm not sure about the side effects either, but I plan to study the matter carefully. There is a [EMAIL PROTECTED]' mailing list. Maybe we should post there, asking for comments and suggestions. 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 realtime privileges. One way to allow (or prevent) access to realtime privileges for any program is via a sysctl global variable. Of course, loading the kernel extension is a privileged operation, anyway. But, I prefer some positive means of blocking it. (2) Using sysctl, set a group id (like `audio') for which realtime privileges are automatically granted. Then, we could just install realtime apps with `setgid audio'. This seems much better than opening things up to *any* application. And, audio applications would not need root privileges any more. This would be a rather big improvement over the current jackstart/jackd situation. (3) We could also define a default realtime group (gid 0 maybe), since `audio' probably does not exist on many distributions. IIUC, this is originally a Debian idea. I don't know how widely it has been adopted. I like it and think it should become a universal Linux convention, allowing access to the sound card as well as realtime privileges. -- Jack O'Quin Austin, Texas
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Mon, Nov 10, 2003 at 10:17:11AM -0600, Jack O'Quin wrote: > > I am cross-posting this to LAD, hoping to get some useful feedback. > > Paul Davis <[EMAIL PROTECTED]> writes: > > > about that patch ... torben hohn wrote, some time ago on LAD (see his > > comment at the end). does anyone have time to check on this? > > > > Have a look at linux security modules. In the 2.5 kernel the > > > patch you propose is not a patch, it is a kernel module. > > [...] > > But, the first step is to figure out if someone is already working on > this. My late-night googling didn't discover any existing project, > but surely someone is doing it by now. If not, I think we should > consider building and distributing one as part of JACK. > > Comments? attached is what i have done today works, but needs to be checked by someone who can judge about the sideeffects. i am not so sure about them. > -- > joq > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language jackcaps-0.1.tar.bz2 Description: Binary data
