Date: Fri, 11 Aug 2000 15:23:18 -0400 From: Christopher Masto <chris@netmonger.net> To: Warner Losh <imp@village.org> Cc: "Chris D. Faulhaber" <jedgar@fxp.org>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/perl Makefile Message-ID: <20000811152305.C12290@netmonger.net> In-Reply-To: <200008111857.MAA36439@harmony.village.org>; from imp@village.org on Fri, Aug 11, 2000 at 12:57:52PM -0600 References: <20000811144136.A12290@netmonger.net> <20000811141800.A14610@netmonger.net> <Pine.BSF.4.21.0008111426270.98390-100000@pawn.primelocation.net> <20000811144136.A12290@netmonger.net> <200008111857.MAA36439@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 11, 2000 at 12:57:52PM -0600, Warner Losh wrote: > In message <20000811144136.A12290@netmonger.net> Christopher Masto writes: > : The reason against it is that it's a standard part of Perl, and a very > : useful one. Without it, those who install from binary, or don't know > : to set this option, will not be able to run setuid Perl programs. > > Good. I want people to have to explicitly do something before setuid > scripts of any kind will work on their system. Why not turn off setuid entirely by default? In fact, compile setuid out of the kernel, and require people to install the kernel source and build a custom kernel before setuid works at all. That would make FreeBSD much more secure, which is of course more important than being useful. In other words, what's so special about interpreted programs (written in a language with a special setuid safety mode) that we should not allow them to be setuid, but still allow it for compiled programs? > : Since Perl has some features specifically designed to aid in writing > : secure setuid programs, removing suidperl could actually cause a > : revenge effect and end up resulting in _more_ security holes. > > They can build it from sources. You can build it from sources. I can (and do) build it from sources. Some people, believe it or not, expect to be able to buy a FreeBSD CD, install it on their machine, and start using it to write and run programs without having to recompile the whole operating system. Some people may not even have that much disk space, or they may be installing it on small machines with limited CPU and RAM. > : This was a strange interaction bug in a program which is very well > : inspected, has a good security reputation, was fixed very quickly, and > : didn't even apply to FreeBSD. It seems a big of an overreaction to > : disable suidperl because of it. > > No. There's nothing in the base system that requires it. There's nothing in the base system that requires ssh. There's nothing in the base system that requires cc. There's nothing in the base system that requires uucp, lpr, cal, or fpr. If the content of the base system was truly determined by its relationship to other parts of the base system, we wouldn't _have_ a base system. The question is not whether some other piece of FreeBSD requires it - it's whether the _users_ require it. > It is a huge piece of software. Sure, the fix came quickly and > didn't impact us this time, but what other bugs are there in this > huge piece of code that will bite us in the future? The same could be said of /kernel, but I wouldn't suggest removing it. > This bug existed despite the multiple reviews of perl. Because it was really a bug in mail. > : If this change is not backed out, I think it is important to at least > : come up with an easy way to get suidperl without building from source. > : We should not force this limitation on casual users. > > Causual users won't have setuid perl scripts. I agree that we might > want to have a package/port that will do this to make it easier for > people that want it to add it to their system. However, I don't have > the time to do that and I really don't think there's a large demand > for it. If others want to send it to me, I'd commit it. If you don't have the time to fix the problem properly, you shouldn't fix it. What you've done is removed a large piece of functionality in a way that requires an extreme step (install all source and buildworld) for the average user to get it back. If it were as simple as changing a sysctl or config file to turn it back on, I would have no complaint at all with the default being off. I will now make a constructive suggestion for an alternate "quick fix". Build and install the binary for suidperl, but don't make it setuid (or executable), and possibly stuck it somewhere under a different name. Then people can at least put it back without having to find room for /usr/src and time to run a buildworld. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000811152305.C12290>