Re: [9fans] Private Namespaces for Linux

[Ronald G Minnich <rminnich@lanl.gov>]

On Tuesday 20 November 2001 15:54, David Gordon Hogan wrote:
> Plan 9 doesn't even have set-uid.

Yeah I know. Those are the guys who made me realize set-uid was stupid, back
when I had no gray hairs.

> But I think you misunderstand.  There are two problems to
> be addressed: (1) rogue fileservers serving up set-uid files
> (not a problem for 9P, but relevant to Unix-based protocols
> like NFS...);

I'm probably missing something. Here is my understanding of how this all
goes. Bear in mind that the last time I thought about this at all was a while
back. I have not tested it on the latest Linux distributions.

I clear setuid bits in the client-side VFS. So you can't get a setuid to even
happen via the kernel exec, even if the bit could move over 9P, which it
can't.

For the libc hack, you are limited to what you can do from user mode, so I am
pretty sure that route is closed too, due to precautions taken in ld.so.
Recall that the libc hack simply redirects stuff like open() to a library,
which translates the ops to 9P and sends the request to a server. This really
depends on ld.so honoring LD_PRELOAD. It doesn't for setuid programs (at
least on systems I have used).

> (2) attacks like the following:
>
> 	$ bind /tmp/passwd /etc/passwd
> 	$ su

1) Kernel-mode VFS: The su will fail as it has no setuid bits.

2) User-mode libc hack: the behavior on systems I use is  that LD_PRELOAD has
    no effect
    on programs with setuid set, and stuff like LD_LIBRARY_PATH is ignored.
    That may have changed -- it should not have, since that was a very early
    sunos exploit ca. 1988 when they first did shared libraries (shared
     libraries are not my favorite thing either). You set LD_LIBRARY_PATH to
         somewhere bad, run su, voila! you're root.
    (I could look but probably these env variables are cleared in the kernel.
     I can't remember which OS I saw this on, but it gets done in some of
  them)

> Disallowing su, passwd, sendmail, etc etc isn't really a solution...

Well, Plan 9 doesn't need stuff like that. Linux shouldn't either, but sadly
it does. That's why I expect Unix-like OSes like Linux to die soon, but then
again I've been expecting that every year for a long time ... however
security is more in the front of people's minds lately. And the things I've
seen done to LInux for security are so ugly, when I see them, I ask people:
have you looked at Plan 9. (two answers: 1) what's that (95%); 2) but nobody
uses that, so you need our gross hacks (5%). )

Say, does anybody remember those same two responses for Unix?

Anyway for this project I decided to ditch priveleged ports and set-uid.
They're just a bad thing.

ron
p.s. check out the dynsys page at uwisc.edu for their discussion of handling
lingering processes under Condor that can commandeer other Condor processes.
They have a cute fix, but under Plan 9 it is totally unnecessary.