8 Dec
2003
8 Dec
'03
10:06 p.m.
Fernando Pablo Lopez-Lezcano <nando(a)ccrma.stanford.edu> 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