21 Mar
2003
21 Mar
'03
7:54 a.m.
At Tue, 18 Mar 2003 12:23:55 -0500,
Paul Davis wrote:
i don't think this type of "permit-all-user-and-app" way will be
integrated into the standard kernel. i mean, it's quite difficult to
convince paranoiac "security guys". this theme is a bit different
from the scheduler changes.
i've thought of an implementation of resource-management wrapper
library using a setuid-root helper binary. the syscalls are replaced
with the wrapper library functions which invoke the helper checking
the access-file wrt
- the caller user/group/hostname
- the caller process exec path
- optionally, the MD5 sum of the binary, or some secret key
and then give the capabilities to the caller process in return.
after changing resources (setsched, mlock), the wrapper reduces the
capabilities again, and go back to the normal operation.
this is somewhat like jackstart does, but in more generic way.
only the helper binary needs setuid-root. you can restrict the
permissions as you like, per user and/or per application.
btw, regarding capabilities: we have already a proc file,
/proc/sys/kernel/cap-bound. unfortunately, this proc is used only to
reduce the capability bits and only init process can set the bits,
i.e. totally irreversible. but, after finding this proc file, i feel
that giving the full capabilities as default in kernel won't be risky
because you can reduce the cap bits in init scripts at any time.
Takashi
Anyway, I think this patch has its place on
linux-kernel. It will most likely
be rejected but it shows that people are interested in these issues...
(Who knows Ingo might get another bright idea... :-)
i agree, but i also raise another angle that i spoke about a couple of
times at zkm this last weekend.
using SCHED_(USER)?FIFO makes no sense if you do not also call
mlockall(2). both (scheduling+memory pinning) are inaccessible without
root or CAP_SYS_RESOURCE capabilities. i think that a very useful
patch would be one that used /proc/sys/kernel/rtperm (or some similar
name) to turn on or off the ability of regular processes to acquire
these "resources". this would then allow us to use SCHED_FIFO,
mlockall(2) and any future SCHED_.+FIFO policies without the absurd
hoops that many people have to jump through at the moment.