From owner-freebsd-questions@FreeBSD.ORG Tue Mar 13 15:16:00 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 694451065677 for ; Tue, 13 Mar 2012 15:16:00 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1538FC14 for ; Tue, 13 Mar 2012 15:15:59 +0000 (UTC) Received: by iahk25 with SMTP id k25so1267194iah.13 for ; Tue, 13 Mar 2012 08:15:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=B+K4rRgn2NBpic7ez1Ik2UqZZkQN/28N8nC6DDWCHCo=; b=COh6R7wwhQrKRRkUo5TxEp7U/inTeiY7qk4N6fMwqpAlfWG72gU+RScmP07fGyLWls ym3DvXYDDnFH9Tb+Mfhd+6yeBA2jSsy2nNTu+615EjgnBMUmBp2nxG4HHlKRmg531Jqg MTCiM5rwwIH06m34RiwP+EcsVkMvyNGMRfkcdEYDkuSk+Rq1gxwjYSjyL18YaX0q6vYw bTPNyUHhGs206oh6jifhBOtSKpYwLCqHOnvnvAVUH+KSyDpCaeBplSmXw/XaU1dhYalf yYSdZtpMoqVK8pFNh+pX9qJlHmunbv+j/YCFrenTxzhJzF8KiNZsxXNAAzHxMLD1AGDe EWaQ== MIME-Version: 1.0 Received: by 10.42.153.10 with SMTP id k10mr21300869icw.24.1331651313209; Tue, 13 Mar 2012 08:08:33 -0700 (PDT) Received: by 10.231.172.194 with HTTP; Tue, 13 Mar 2012 08:08:33 -0700 (PDT) X-Originating-IP: [93.221.190.44] In-Reply-To: <4F5E4C2A.1020005@tundraware.com> References: <4F5E4C2A.1020005@tundraware.com> Date: Tue, 13 Mar 2012 16:08:33 +0100 Message-ID: From: "C. P. Ghost" To: Tim Daneliuk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlt1TVD2cvWncdG7Df6gU4r0oQqRjiXSM1f4cU5Yrg18Wwe9hdxswNC0phuu2immvd78e+X Cc: FreeBSD Mailing List Subject: Re: Editor With NO Shell Access? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 15:16:00 -0000 On Mon, Mar 12, 2012 at 8:19 PM, Tim Daneliuk wrote= : > I have a situation where I need to provide people with the ability to edi= t > files. =A0However, under no circumstances do I want them to be able to ex= it > to the shell. =A0 The client in question has strong (and unyielding) Info= Sec > requirements in this regard. If the requirements are THAT hard, I think it would be best to do it the good ole fashioned way: modify the source code of their favorite editor, by patching out ALL calls to system(2), exec*(2), popen() et al. This way, you'll be sure that editor binary won't call out ANY external process whatsoever. A little bit less secure, but based on the same idea, would be to provide replacements for those process-creating functions in a custom library, say, libnofork.so where each of these functions immediately return or signal an error like EPERM instead of ultimately doing the syscall. Then link your client's editor with -lnofork to mask the original libc definitions. It is a little bit less secure than manually removing or commenting out calls to system(), exec*(), popen*() etc, because the editor could at least in theory call dlopen() on the original libc, where the functions are still there, or it could even issue the kernel syscalls directly, without going through libc... although that is very unlikely with the usual editors. It is also less secure, because from within this modified editor, the user could read the contents of libc.so into libnofork.so, and then restart the editor. But you get the basic idea. Alternatively, you may want to look into ways to disable forking() in general for a process. Some old Unices provided a way to selectively disable certain syscalls based on some root-definable administrative per-user or per-application policy, but I don't know whether this is possible with FreeBSD. Perhaps the new Capsicum [1] provides this, or will in the foreseeable future? I have not looked into it yet. [1]: http://www.cl.cam.ac.uk/research/security/capsicum/ > So ... are there editors without this feature? =A0Can I compile something= like > joe or vi to inhibit this feature? Yes, see above: provide a replacement library and link against that. Consider static linking for slightly increased security, and make sure the user can't modify the editor binary, can't modify any dynamic libraries it links against, and can't replace that binary with another binary. Security is like an onion. > Tim Daneliuk =A0 =A0 tundra@tundraware.com > PGP Key: =A0 =A0 =A0 =A0 http://www.tundraware.com/PGP/ Regards, -cpghost. --=20 Cordula's Web. http://www.cordula.ws/