Date: Thu, 17 Dec 1998 00:20:33 +0800 From: Peter Wemm <peter@netplex.com.au> To: Tony Finch <dot@dotat.at> Cc: current@FreeBSD.ORG Subject: Re: modification to exec in the kernel? Message-ID: <199812161620.AAA10511@spinner.netplex.com.au> In-Reply-To: Your message of "Wed, 16 Dec 1998 16:07:35 GMT." <E0zqJU7-0000RJ-00@fanf.noc.demon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Finch wrote: > Matthew Dillon <dillon@apollo.backplane.com> wrote: > > > > I don't see the point. Let me put it this way: If you give > > the user a non-chrooted environment but do not give the user access > > to any suid/sgid programs, how is this different from giving the user > > a chroot'd environment without access to any suid/sgid programs? The > > only difference that I can think of is access to /tmp. I don't see how > > the chroot'd environment is any safer then the non-chroot'd environment. > > You can throw away a lot of stuff from the chrooted environment and > still leave the system useful to the admins. AFAICT breaking root in > an environment like this is much more like trying to do so over the > network because the machine's services are only accessible in that > sort of way. I've come into this late, I have not seen the original parts of this thread. However, it looks like it might be vaguely related to something I did for somebody ages ago (and is still in use) as a hack to solve a problem at the time. Basically, the objective was to stop users downloading and running random binaries on the systems they had shell access to without those binaries being "blessed". What we did was: - Overload the sticky (t) bit - this was easiest since most things knew of it's existance already, and things like chmod didn't need tweaks. - Users (uid >= 5000) could run any system binary they had access to, or any user binary that hat the sticky bit set. - the "t" bit could be set (by root) on a binary owned by a user. - we were tempted by but didn't use flags since +t was convenient. Basically that stopped people downloading and running things like 20 copies of rc5des, various password cracking programs, IRC bots etc. The determined could run tcl or perl scripts if they wanted to, but nobody ever did. This was implemented^H^H^H^H^H^H^Hhacked in by having kern_exec.c look at the uid of the invoker, the owner uid of the file and whether the +t bit was set. The vfs was (slightly) tweaked to clear the sticky bit if the file was written to. The whole thing wasn't exactly what I'd call clean. It did stop the clueless from doing stupid things, which is what it set out to. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812161620.AAA10511>