Re: [linux-audio-dev] Sharing Music
On Tue, 9 Dec 2003 12:27 pm, Hans Fugal wrote: > As in, how do I share my own? What licenses or other scheme do you all > use for music that you create and would like to be widely distributed, > with or without any other restrictions. What considerations do you take > into account? Personally, I would be inclined to use the 3rd Creative Commons license. Various choices at http://creativecommons.org/license/ Another angle I am interested in is to use the GPL to release some music and all it's "source code" so that if others wanted to reuse my stuff then they _have_ to also have to make their changes publically available... ie; I'd like to also "share" the creative process as well as the end results. > disclaimer: I don't have any cool music to release (yet), although I have a > few almost-cool works for the extremely curious... Yep, very intested in any linux/open music... got a URL ? --markc
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
[linux-audio-dev] Sharing Music
As in, how do I share my own? What licenses or other scheme do you all use for music that you create and would like to be widely distributed, with or without any other restrictions. What considerations do you take into account? disclaimer: I don't have any cool music to release (yet), although I have a few almost-cool works for the extremely curious... -- Hans Fugal | De gustibus non disputandum est. http://hans.fugal.net/ | Debian, vim, mutt, ruby, text, gpg http://gdmxml.fugal.net/ | WindowMaker, gaim, UTF-8, RISC, JS Bach - GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460 pgp0.pgp Description: PGP signature
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] deconvolver for IR creation anyone?
I would be interested in this project too. What I'm looking for is actuallay an anti-reverb that will be able to cancel reverbs in a listening room, well always in conjunction with the listener position. The other useful thing would be a phase-filter to correct the phases coming out from a two or three way loudspeaker to get clarity in the sound similar to high-end speakers. I'm surprised that you mind modern consumer soundcards not linear, after all the sigma-delta converters used in most of todays soundcards are supposed to be perfectly linear and it was one of the reasons of their adoption. Apostolis Uwe Koloska wrote: Hello, I am looking for a deconvolver, that is able to produce impulse responses from sinus sweeps (and especially the exponentially sweeping sine wave introduced by Farina). Do you have any suggestions or at least tips to start an implementation by myself? Recently I managed to use the mls tools from nwfiir to produce an IR of my microverb. I had to learn the hard way, that simple soundcards are not able to be used as MLS source because of the non linearities. Even a simple DA-AD loop gives a result wave that mls2imp cannot cope with. But an empty loop with an US-122 (unfortunately not with linux for now) gives something very near to a dirac impulse! The hunt for the linux convolution reverb has started ;-) Uwe
[linux-audio-dev] deconvolver for IR creation anyone?
Hello, I am looking for a deconvolver, that is able to produce impulse responses from sinus sweeps (and especially the exponentially sweeping sine wave introduced by Farina). Do you have any suggestions or at least tips to start an implementation by myself? Recently I managed to use the mls tools from nwfiir to produce an IR of my microverb. I had to learn the hard way, that simple soundcards are not able to be used as MLS source because of the non linearities. Even a simple DA-AD loop gives a result wave that mls2imp cannot cope with. But an empty loop with an US-122 (unfortunately not with linux for now) gives something very near to a dirac impulse! The hunt for the linux convolution reverb has started ;-) Uwe -- voiceINTERconnect www.voiceinterconnect.de ... smart speech applications from germany
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
