In message <9807091617.ZM3971at_private> Matt Evans writes: : a.jar() and b.jar() are going to both get called before other_stuff(), : but you have no way of knowing in which order a.jar() b.jar() get called with : respect to each other. does jar() need to drop privs ? i hardly think so. : what happens when "class lazy_programmer{};" comes along ? must all of its : constructors also "drop privs" as well ? if every function "drops privs" : before main() ever starts, and every function does so in some random order, i : fail to see how you can create a useful set[ug]id program. 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 up side is that chmod 4777 /bin/sh no longer gives you a setuid shell. Code would have to be more explicit in its use of privs. This is likely a good thing. The down side is that chmod 4777 /bin/sh no longer gives you a root sheel. ALL setuid programs must be changed to run on a system like this, or they will fail to operate. This would fix the class of problems that are characterized by code running with too many privs to access shared resources. This seems like an interesting enough set of problems to go after. I suspect that you don't want to do this in crt0.o because a roughe program could easily bypass that check. Kernel support seems a must. Doesn't do squat about the problem of buffer overflows... 2) have an option to ld that refuses to allow any global ctors to be called. This way you could have some safety in the writing set[gu]id programs that are written in languages that allow this, or call library routines that allow this. Comments? Warner
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:03:10 PDT