lkml.org 
[lkml]   [1999]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: caps in elf headers: use the sticky bit!
David L. Parsley writes:
> 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!

I fundamentally question the need for this. Once a binary grants
privileges, it is no longer an ordinary file. It is a system file. Who
cares if jbloggs was the originator? We have the same setup now with
suid-root binaries. The "originator" (whoever compiled it) is
different than the "owner" (root) if the binary grants
privileges. This is not causing a problem.
> > - 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?!?

Now why would root (or the capabilities granting utility) remove
execute permission in the first place?

> > > 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.

Gee, David, I sure do appreciate you assuming that I didn't think
about the issues before mailing.

No, I've read the various posts on this topic and thought about the
issues. I just don't agree with your view. Deal with it.

> 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.

Big deal.

> your broken ass system:

Nice words.

> -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?

Strange idea to grant capabilities to a binary which is only run by
root.

> 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.

What's this 't' bit needed for? Oh, I get it. You want to grant
capabilities! Wow. How useful, since root already has those
capabilities. Oh well. Just a few more cycles doing nothing useful.

Instead, why not run portmap under a special account? Then it makes
sense granting privileges.

Alternately, if you *really* want to run this as root, just fill in
the section of the ELF header which removes all but the required
capabilities. *Note that this does not require privileged filesystem
bits, since you can always reduce capabilities*.

> 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)

Nice emotive words again.

> Now restart named and break it again.

Funny scenario. What I don't see is why named is being run by a
privileged user in the first place. Why not have a named account? Or a
daemon account?

> I prefer:
> -rwsr-xr-t 1 syssvc root 432880 Jan 4 01:07 named*

I prefer:
named: inode: euid=0, suid
caps: ports

and then run named under the daemon account.

> 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?

Why on earth would you want to do that anyway? Marking a binary
suid-root means "give executor all privileges".

> 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.

Doesn't help me when there are files with the sticky bit in /usr. Oh,
yeah, I forgot to mention, we have junior administrators who can write
to certain parts of /usr but who don't have root access. I don't want
them hacking in either.

> 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.

No, you've just made assumptions about the suid-root scheme which
create these non-problems.

> Just because I don't have any patches in the kernel doesn't make me
> a jackass.

Interesting point. Erm, so why did you raise it? I haven't seen anyone
denigrate you because you don't have patches in the kernel. Who said
this? I must have missed it. Tell me who it is and I'll abuse them
privately.

> 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.

So far all the "problems" I've seen you raise are non-problems. They
seem to stem from a set of assumptions which I for one don't share. I
can guess at some of those assumptions, but it would help if you
enumerated them. It may be more productive for me to directly
challenge those assumptions rather than challenge their results.

And let me say it again: we *can't* use the sticky bit, because it's
insecure. And disabling over NFS is no good, because I *want* NFS
support for capability-granting binaries. All the world is not
Linux-2.2.

Regards,

Richard....
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [from the cache]
©2003-2011 Jasper Spaans