From owner-freebsd-hackers Thu Jun 11 13:24:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA18473 for freebsd-hackers-outgoing; Thu, 11 Jun 1998 13:24:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18291 for ; Thu, 11 Jun 1998 13:23:21 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id NAA03906; Thu, 11 Jun 1998 13:23:07 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: jbryant@unix.tfs.net cc: njs3@doc.ic.ac.uk (Niall Smart), freebsd-hackers@FreeBSD.ORG Subject: Re: [Fwd: Secure Ping 1.0] In-reply-to: Your message of "Thu, 11 Jun 1998 15:01:22 CDT." <199806112001.PAA22953@unix.tfs.net> Date: Thu, 11 Jun 1998 13:23:06 -0700 Message-ID: <3902.897596586@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > the original "secure-ping" idea presented is useful for preventing > abuse by the casual unix user. anyhow, what kind of idiot keeps a > compiler user-accessable in an untrusted environment?! Perhaps the kind of idiot who also knows that it makes about as much sense to "secure" a system that way as it does to install a locking door on a cardboard shack. :-) There are enough free shell accounts given out on the net that any reasonably determined newbie cracker can compile something somewhere else or just use the copy of PERL which is invariably found somewhere to do socket manipulation. You can't really control the creation or importation of strange executables onto your system, but what you can control is the execute bit itself. My first intro to this was what Paul Vixie first did on gatekeeper.dec.com - joblow could log in and FTP over all the ICMP killers they wanted, but any attempts to chmod them executable would just be silently ignored - it was blocked at the syscall level. I also believe there it was a kernel variable he could just set and unset with the debugger to turn this off when he himself needed to install something, but FreeBSD could probably more effectively key off the secure level and have "no new execs" as a kernel option to go along with a securelevel > 1, or something. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message