[26230] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Linux kernel setgid implementation flaw

daemon@ATHENA.MIT.EDU (FozZy)
Fri Jul 19 12:00:31 2002

Date: Fri, 19 Jul 2002 14:15:54 +0200
From: FozZy <fozzy@dmpfrance.com>
To: bugtraq@securityfocus.com
Message-Id: <20020719141554.694f07e1.fozzy@dmpfrance.com>
In-Reply-To: <20020719045418.5a144713.fozzy@dmpfrance.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thanks to everyone for your answers. To sum up:
- this is correct standard unix98 behavior
- the linux setgid manpage is wrong.

Hey, sorry for pointing out a vulnerability in a manpage :p

Better to know that. set*id calls are tricky. I had checked the FreeBSD behavior, it was the same as what both linux and freebsd manpage told: "the setgid() function sets the real and effective group IDs and the saved set-group-ID of the current process to the specified value", no matter what the user id is (super-user or not).

I now realize that both behaviors are acceptable: 
- FreeBSD setgid syscall is "POSIX1 compliant with _POSIX_SAVED_IDS *not* defined with the Appendix B.4.2.2 permitted extensions".
- Linux uses more current standards (but should update its manpage; so beware when porting FreeBSD apps to linux ;)

FozZy
Hackademy & Hackerz Voice Director

PS: Such an error in a manpage, for people (like me) who are not standard unix98 gurus, is dangerous.
For developpers of course, but i am also thinking about system administrators trying to set up a more secure system by removing the setuid bit from some programs, and tuning file permissions (and maybe hacking a bit the program) so that the setgid bit only makes the job. I used to do that. It could actually result in lower security !

home help back first fref pref prev next nref lref last post