[9026] in bugtraq
Re: Wiping out setuid programs
daemon@ATHENA.MIT.EDU (der Mouse)
Sun Jan 10 15:41:19 1999
Date: Sun, 10 Jan 1999 01:54:39 -0500
Reply-To: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
From: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
To: BUGTRAQ@NETSPACE.ORG
> Several people have asked about the costs and benefits of splitting a
> setuid program into an unprivileged user process and a non-setuid
> daemon.
> C=08Co=08os=08st=08ts=08s.=08. [...]
[For those who don't feel like working it out, that's "Costs." with
quoted-printable backspaces attempting overstrikes.]
Your bias is showing. You're missing a cost: the program doesn't work
if the daemon isn't running. (For whatever reason: single-user, it
crashed, etc.) You're missing another cost: convincing some
appropriate "kernel implementor" to provide getpeereuid(). (It's not
just a matter of doing it - for OSes less into the kitchen-sink
philosophy than Linux, there's the question of whether that's the right
way to go - and even if it does go in, I think your "five minutes" is
grossly optimistic, especially when you add regression testing,
documentation, maintenance, etc, etc.)
> It shouldn't take more than five minutes for a kernel implementor to
> support getpeereuid(). For example, Linux has "struct ucred
> peercred" inside struct sock,
A peer credentials structure in every socket, just to support AF_LOCAL
credentials? I'd say this belongs in (the Linux analog of) the struct
unpcb. (Not that Linux cares what I think. :-)
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
