Messages in this thread | | | Date | Mon, 12 Apr 1999 20:43:37 -0400 (EDT) | From | "David L. Parsley (lkml account)" <> | Subject | Re: caps in elf headers: use the sticky bit! |
| |
Hi Richard,
On Tue, 13 Apr 1999, Richard Gooch wrote:
> All of these are non-problems: > > - ls can be updated if you want to see who the original owner > was. Note you *only* need to change ls
NOT just ls, but _every_ program who wants to know who the file owner _really_ is!
> - the number of privileged binaries is so small that accounting them > in root's quota is fine. Besides, these binaries *are* special, and > there is no strong reason to "charge" them to the quota of the > originating user. Also, most of these privileged binaries are still > going to be made by root.
Quota is just a symptom of the deeper problem: storing 'setuid 0' in the fs is just a lie in many cases; it might not be setuid, it might not be owned by root. What about the case of '-rws------ root root ... mybinary', where _I_ am the actual owner of the file, but I can't even execute the darn thing?!?
> > Please give a little bit of thought to the sticky bit idea, and look at > > the problems with it and solutions suggested. > > Overloading the sticky bit is just plain broken. It opens up a > whopping big security hole. It just cannot be used. End of story.
Gee, Richard, I sure appreciate you contemplating my suggestion for a few nanoseconds.
Here, allow me to give you some much better examples to think about:
Many, MANY system services aren't run setuid root in the first place, because they are RUN by ROOT.
your broken ass system:
-rwsr-xr-x 1 root root 28240 Mar 24 23:55 portmap*
Cool, we've modified portmap and crippled it's capabilities! Now, every binary that was formerly just _run_ by root is now setuid root! Sound good?
with my broken ass system:
-rwxr-xr-t 1 root root 28240 Mar 24 23:55 portmap*
My portmap is completely harmless under older kernels.
Or how about this; consider the recent 'named' remote root exploit. Black hat breaks the hole in named and crashes it. Oh but wait! No caps? No problem! Modify the binary with all the caps you need (and uid root), then mark it setuid root again; after all, it doesn't take any special caps to setuid to your own uid! (or maybe it does in this grand new bastardization of a capabilities system) Now restart named and break it again.
I prefer: -rwsr-xr-t 1 syssvc root 432880 Jan 4 01:07 named*
Yes, I reallize your case is fixable as well, but think about all the repercussions. For instance, what if root wants to mark a binary setuid root that has no caps? Should this require some cap?
Worried about /home being full of sticky bit binaries? Mount it with caps off! So far, the sticky bit problems are _EASY_, and the solution gives us a _lot_ of flexibility and compatibility just not present in the setuid 0 solution.
Keep looking, and you'll keep seeing why using 'setuid 0' is at _least_ as broken, if not a lot _more_ broken, than using the sticky bit.
Just because I don't have any patches in the kernel doesn't make me a jackass. Other people have seen the problems with the sticky bit idea, but have made suggestions for solving them. When I was looking at the setuid 0 idea, I kept finding problems that were ugly to solve. Don't get me wrong, I'm still weighing setuid 0 as an option, but it was fixing the problems with it that led me to the sticky bit.
> > Regards, > > Richard.... >
- -- David L. Parsley Network Specialist City of Salem Schools
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |