On Fri, Jul 10, 1998 at 02:07:54PM -0600, Warner Losh wrote: > > And you have no way of knowing if they get called in such a ways as to > put libc at risk. > > I see two solutions to this problem: > > 1) set?id programs need to be modified. They need to come up > with their privs disabled and explicitly enable them for > the work they need to do. This is definitely a change in > the traditional behavior of how set?id works. It would buy > a few things at the cost of a few other things. I'm > surprised that I've need seen references to this in the > literature. > The POSIX.6 features implemented in Linux 2.1 supports this [the filesystem support for this will not be integrated into 2.2 so you can't use this "out-of-the-box"]. What basically happens is that each executable has an allowed set which states which capabilities(*) the program is allowed to obtain, a set of forced capabilities which it will obtain regardless of whether the executing process has them in its inheritable set, and an effective bit which indicates whether the executable is capability "smart" or "dumb". An executable that is capability smart will start with capabilities only in its allowed set, not in its effective set. It will therefore explicitly have to raise the individual capabilities when it wants to use them. A capability dumb program will start with effective=permitted capabilities. * These are POSIX.6-style capabilities which is similar to VMS or Trusted Solaris privileges, not KeyOS or _real_ capabilities. It is a bitmask [or, actually 3: inheritable, permitted and effective]. In Linux 2.1 all privilege checks in the kernel use these capabilities instead of checking for whether the euid==0 or not. uid==0 is simply emulated in the set*id calls by setting the appropriate capability bits. astor -- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:04:28 PDT