Re: [linux-audio-dev] Linux Security Module for realtime audio

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Linux Security Module for realtime audio
From: torbenh_AT_gmx.de
Date: Tue Dec 09 2003 - 16:02:31 EET


On Mon, Dec 08, 2003 at 05:12:50PM -0600, Jack O'Quin wrote:
> 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()...
>
> [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 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).

uhh... how does that happen ?
i will look at the dummy security...

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Dec 09 2003 - 16:08:22 EET