Gavan Fantom wrote:

> Steven M. Bellovin wrote:
>
>> 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?
>
>
> [...]
>
>> It would be nice if we could make it easy for non-root to debug
>> setuid programs.
>
>
> Suppose you have a program set-id (non-root) user A, being run by user
> B. While it's clear that you wouldn't want user B being able to read
> the core dump as it might expose A's private data, I'm not sure it'd
> be a good idea for A to own it either. Granted, A could grab B's
> private data by modifying the program, but even so I'm not sure we'd
> want to just give A a bunch of B's data.
>
Yes, this is a valid concern.  Imagine A is "http" or someother
administrative user.  If there is a bug in the program, maybe someone
can exploit this to get access (e.g. via HTTP or somesuch) to data
belonging to B that is locked away in a core dump.

I think that in the vast majority of cases, the set-id bit is used to
provide a way for programs to access some shared system resource (e.g.
being setid root to access low numbered TCP ports), and this privilege
is typically set up by some system administrator with root powers.

Debugging programs such as these typically also falls under the umbrella
of someone with a root account, and in those cases where it doesn't,
close coordination with such a user is typically needed (e.g. to install
a new version for testing.)  The root user can copy or move/chown the
core files on demand this way, and we avoid the sticky issue of ownership.

The one thing that a having the ownership be root doesn't do is limiting
the space.  If necessary, creating a new administrative user ("core"?)
could be used (tunable via sysctl), but I'd argue that we can solve that
problem later.

Initially, I like the idea of stashing all setid core dumps in a
particular directory, and having them root-owned.  (Probably also root
group ownership.)  The file mode should be 600.

While it doesn't meet every desire, this approach provides more
functionality than we have today, and likely meets the needs of the
overwhelming majority of the users who would want to debug setid
programs (at least legitimately).

Actually, if the directory approach is used, then a sysctl to enable
this feature is not strictly required -- testing for the presence of the
directory would be adequate.  But the sysctl directive is a bit more
explicit, and probably aesthetically more pleasing.

-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134