Subject: Re: [linux-audio-dev] Linux Security Module for realtime audio
From: Jack O'Quin (joq_AT_io.com)
Date: Tue Dec 09 2003 - 01:12:50 EET
> 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...
torbenh_AT_gmx.de 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 linux-security-module_AT_wirex.com 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
This archive was generated by hypermail 2b28 : Tue Dec 09 2003 - 01:14:33 EET