Date: Sun, 13 Aug 2000 00:28:58 -0600 From: Warner Losh <imp@village.org> To: arch@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/perl Makefile Message-ID: <200008130628.AAA06887@harmony.village.org> In-Reply-To: Your message of "Sat, 12 Aug 2000 23:06:40 PDT." <20000812230640.A78736@dragon.nuxi.com> References: <20000812230640.A78736@dragon.nuxi.com> <20000812220942.B77195@dragon.nuxi.com> <200008111949.MAA26238@pike.osd.bsdi.com> <200008111951.NAA64094@harmony.village.org> <20000812220942.B77195@dragon.nuxi.com> <200008130550.XAA06630@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20000812230640.A78736@dragon.nuxi.com> "David O'Brien" writes: : Its the only automatic way I can think of to turn on suidperl and later : turn it back off (easily) when I replace that last suidperl script. : IMHO, it isn't that much different than turning on the various daemons : that run as root. I guess I worry about an attacker replacing rc.conf and/or suidperl with something nasty. Of course, if it is rc.conf, you are SOL, so I'll not worry about that case. Replacing one binary in /usr/bin is likely to be tantamount to giving the person who could make that replacement root. So I guess these worries are not big deals because the rest of the system already is vulnerable (but so is everybody else, except for the md5 signed crowd of TrustedBSD (or is that SecureBSD)). It just makes me nervous to potentially turn on and off the setuid bit of an arbitrary file (even if it is well named) at boot time. I think it violates POLA in that we expect to store the permissions of the files in the file system. I'm not sure, so I'll need to cook on this overnight and see what my subconscious spits up overnight. : Rod's SUIDPERL_MODE would also be a fine rather than ENABLE_SUIDPERL. Boiled down, I think that's the HOW vs WHAT argument. AFAIK, There's only really two different modes for suidperl. Working (4511) and nonworking (444, 511, etc). One cannot control the ownership of the program, because then it can't do its thing. Since it is a binary choice, I thought ENABLE_SUIDPERL would be better. If we needed to do other things to enable/disable suidperl, then suidperl_mode would need a friend, maybe, or we'd have to check for the setuid bit. In addition, you control the permissions of access to the setuid perl stuff via the permissions on the setuid shell scripts that you have. I think that the current scheme (modulo bugs) with an enhanced warning/explaination about how to enable suidperl is the right way of going. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008130628.AAA06887>