> 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 Linux. We should really be running that with these modules, if we can. What do the kernel developers use? -- joq