From: Steven M. Bellovin (smbcs.columbia.edu)
Date: Fri Jan 13 2006 - 14:50:50 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

In message <43C80E13.20403tadpole.com>, "Garrett D'Amore" writes:

>
>Btw, we might want kern.defcorename and a new kern.defsuidcorename
>sysctl, the latter can use a full path name, without imparing ordinary
>behavior that we are all used to for non-suid processes.
>

I think that that's a very good idea -- the namespace isn't cramped
enough for us to want to overload that field.

I'm still trying to wrap my brain around all of the security
implications of this proposal. I don't think they've all come out yet.
For example, we can't just go with the effective uid for the owner of
the dump; many setuid programs shed their permissions at some point.
We need the saved uid. We also have to worry about setgid programs --
will the real user own the core dump?

The need for some such facility is clear. Restricting it to root and a
particular directory is at best a hack -- it's saying "we'll give you
something, but we don't really understand what we're giving you, so use
it with caution and let us know if you figure it out". One of the very
attractive things about Unix, way back when, was how many of its
facilities weren't privileged. That was a lovely change from, say,
TSO. SetUID, in particular, was designed as a general privilege
elevation mechanism, one not restricted to the system administrator.
It would be nice if we could make it easy for non-root to debug
setuid programs.

                --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]