[lkml]   [1999]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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

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

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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.088 / U:2.424 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site