[9028] in bugtraq
Re: Wiping out setuid programs
daemon@ATHENA.MIT.EDU (Nick Maclaren)
Sun Jan 10 16:47:13 1999
Date: Sun, 10 Jan 1999 11:16:00 +0100
Reply-To: Nick Maclaren <nmm1@CUS.CAM.AC.UK>
From: Nick Maclaren <nmm1@CUS.CAM.AC.UK>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Sat, 09 Jan 1999 10:58:54 GMT."
<19990109105854.3085.qmail@cr.yp.to>
"D. J. Bernstein" <djb@CR.YP.TO> wrotes:
> Costs. 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, and a SO_PEERCRED macro in sys/socket.h, used by the
> following four syscalls:
> . . .
> There's similar code to handle gid (and pid). The entire implementation
> is about twenty lines long.
Hmm. I admire the amount of careful design and validation that you seem
to regard as necessary for kernel modifications.
For example, consider the following sequence of operations:
Process A running with effective uid fred and saved uid root creates
a socket, and then changes to effective uid joe.
Process B connects to the other end, process A changes to effective
uid alf, and then process B calls getpeereuid.
The following questions immediately spring to mind:
1) Which uid (fred, joe or alf) will it return?
2) Are there any circumstances under which it won't?
3) Is this the correct behaviour, anyway?
4) Are we sure that everyone will agree and do the same?
This is definitely a facility that could be useful. But surely we
know that designing operating system primitives for security
enhancement needs long and careful thought, to avoid obscure and
subtle design errors that cannot be fixed later?
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
