Date: 18 Nov 1998 15:34:50 -0600 From: Joel Ray Holveck <joelh@gnu.org> To: William McVey <wam@sa.fedex.com> Cc: Mikael Karpberg <karpen@ocean.campus.luth.se>, dillon@apollo.backplane.com (Matthew Dillon), hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Message-ID: <86d86kit1h.fsf@detlev.UUCP> In-Reply-To: William McVey's message of "Tue, 17 Nov 1998 18:45:47 -0600" References: <199811180046.SAA23057@s07.sa.fedex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> And what's wrong with popen() even if I was? > popen (at least historically) passes down environment variables (such as > IFS and LD_LIBRARY_PATH) which can cause a program popen()ed by a setuid > program (or setgid program for that matter) to run code the author perhaps > didn't expect. First off, it was designed as a basic something to show the idea, and I recall Mikael making it quite clear that he expected it to be needing work. If we are going to pick at nits, we'd also point out that a) IFS is irrelevant since the program in question would not be calling sh, b) LD_LIBRARY_PATH is irrelevant, since this would need to be in /bin or /sbin and statically linked, c) why the hell pick nits? Let's give him a "good idea go with it" or "bad idea because..." and let the details of implementation be examined later. I'm sure that Mikael would be happy for you to work with him on getting that type of code right. >> Again... I didn't write that piece of code as a suggested code, but >> more like a well-written pseudo-code. I think this might have been >> a mistake. I should have used less correct c-code. > I replied pointing out the bug simply to show that even simple (and > apparently correct) programs can have mistakes in them, and to > demonstrate what I've been trying to convince people of. A new > group for programs like xlock or check_pw to be setgid to would be > better than requiring these programs to be setuid root. Good point. Now, do we see any reason that somebody may be able to get egid shadow privs? (Since egid is frequently not so well controlled as euid privs.) What advantages does the check_pw approach still have, coupled with sgid shadow? I pointed out hardware authentication devices and OTPs earlier; any others? > I'm somewhat new on the security list. What does it take to get > changes decided on? Does something like this need 'general consensus > and running code' (ala IETF), is something like this voted on, or does > someone just go out and do it once they get convinced? In general, most FreeBSD development means get public opinion if it's major (like this), somebody writes a patch, and sends in a pr. Then lobby a committer to merge it. -- Joel Ray Holveck - joelh@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86d86kit1h.fsf>