Date: Tue, 13 Mar 2012 16:08:33 +0100 From: "C. P. Ghost" <cpghost@cordula.ws> To: Tim Daneliuk <tundra@tundraware.com> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: Editor With NO Shell Access? Message-ID: <CADGWnjW5kzreHu=bfcc2X3jk7ffaokMre0Su%2BXvkPvA31sfycw@mail.gmail.com> In-Reply-To: <4F5E4C2A.1020005@tundraware.com> References: <4F5E4C2A.1020005@tundraware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 12, 2012 at 8:19 PM, Tim Daneliuk <tundra@tundraware.com> 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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADGWnjW5kzreHu=bfcc2X3jk7ffaokMre0Su%2BXvkPvA31sfycw>