9 Dec
2003
9 Dec
'03
10:04 a.m.
On Mon, Dec 08, 2003 at 05:12:50PM -0600, Jack O'Quin wrote:
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...
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.
uhh... how does that happen ?
i will look at the dummy security...
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
torbenh(a)gmx.de writes:
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.
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 :] 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. 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
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(a)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).