Re: Editor With NO Shell Access?
Tim Daneliuk wrote: > ... we're talking about almost 1000 systems > here. That's a whole bunch of configuration... Had you considered using something along the lines of sysutils/puppet? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On 3/13/2012 10:43 AM, Tim Daneliuk wrote: On 03/13/2012 01:39 AM, Joshua Isom wrote: On 3/12/2012 5:23 PM, Polytropon wrote: On Mon, 12 Mar 2012 15:19:51 -0700, Edward M. wrote: On 03/12/2012 03:10 PM, Polytropon wrote: /etc/shells to work, but a passwd entry like bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe I think this would not let the user to login,etc I'm not sure... I assume logging in is handled by /usr/bin/login, and control is then (i. e. after successful login) transferred to the login shell, which is the program specified in the "shell" field (see "man 5 passwd") of /etc/passwd. How is login supposed to know if the program specified in this field is actually a dialog shell? From "man 1 login" I read that many shells have a built-in login command, but /usr/bin/login is the system's default binary for this purpose if the "shell" (quotes deserved if it is an editor as shown in my assumption) has no capability of performing a login. Are they logging in from the console or from ssh? If it's from a console, I'd send them directly into a jail with limited file system access, so that excecutables don't matter. If it's from ssh, I'd do the same thing. Assume they can break out of the editor or that something will happen. Make it minimalist about what they can do. Use the /rescue/vi in an empty jail with the files available. Don't think about changing editors, change the system. That's a really good idea, but we're talking about almost 1000 systems here. That's a whole bunch of configuration... Here's the simplified form. mkdir -p /edit_jail/usr/share/misc mkdir -p /edit_jail/var/tmp cp /usr/share/misc/termcap* /edit_jail/usr/share/misc/ cp /rescue/vi /edit_jail mount_nullfs /allowable_files /edit_jail/files jail -c path=/edit_jail command=/vi Only the last command would need to be done at login. If you want a different editor, you'll have to deal with libraries, etc. Most only need libc and libncurses so it's not that big a deal. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On 03/13/2012 01:39 AM, Joshua Isom wrote: On 3/12/2012 5:23 PM, Polytropon wrote: On Mon, 12 Mar 2012 15:19:51 -0700, Edward M. wrote: On 03/12/2012 03:10 PM, Polytropon wrote: /etc/shells to work, but a passwd entry like bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe I think this would not let the user to login,etc I'm not sure... I assume logging in is handled by /usr/bin/login, and control is then (i. e. after successful login) transferred to the login shell, which is the program specified in the "shell" field (see "man 5 passwd") of /etc/passwd. How is login supposed to know if the program specified in this field is actually a dialog shell? From "man 1 login" I read that many shells have a built-in login command, but /usr/bin/login is the system's default binary for this purpose if the "shell" (quotes deserved if it is an editor as shown in my assumption) has no capability of performing a login. Are they logging in from the console or from ssh? If it's from a console, I'd send them directly into a jail with limited file system access, so that excecutables don't matter. If it's from ssh, I'd do the same thing. Assume they can break out of the editor or that something will happen. Make it minimalist about what they can do. Use the /rescue/vi in an empty jail with the files available. Don't think about changing editors, change the system. That's a really good idea, but we're talking about almost 1000 systems here. That's a whole bunch of configuration... -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
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 edit > files. However, under no circumstances do I want them to be able to exit > to the shell. The client in question has strong (and unyielding) InfoSec > 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? Can 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 tun...@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On 3/12/2012 5:23 PM, Polytropon wrote: On Mon, 12 Mar 2012 15:19:51 -0700, Edward M. wrote: On 03/12/2012 03:10 PM, Polytropon wrote: /etc/shells to work, but a passwd entry like bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe I think this would not let the user to login,etc I'm not sure... I assume logging in is handled by /usr/bin/login, and control is then (i. e. after successful login) transferred to the login shell, which is the program specified in the "shell" field (see "man 5 passwd") of /etc/passwd. How is login supposed to know if the program specified in this field is actually a dialog shell? From "man 1 login" I read that many shells have a built-in login command, but /usr/bin/login is the system's default binary for this purpose if the "shell" (quotes deserved if it is an editor as shown in my assumption) has no capability of performing a login. Are they logging in from the console or from ssh? If it's from a console, I'd send them directly into a jail with limited file system access, so that excecutables don't matter. If it's from ssh, I'd do the same thing. Assume they can break out of the editor or that something will happen. Make it minimalist about what they can do. Use the /rescue/vi in an empty jail with the files available. Don't think about changing editors, change the system. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On 03/12/2012 05:33 PM, Robert Bonomi wrote: From owner-freebsd-questi...@freebsd.org Mon Mar 12 17:46:04 2012 Date: Mon, 12 Mar 2012 15:47:59 -0700 From: "Edward M." To: Polytropon Cc: freebsd-questions@freebsd.org Subject: Re: Editor With NO Shell Access? On 03/12/2012 03:23 PM, Polytropon wrote: On Mon, 12 Mar 2012 15:19:51 -0700, Edward M. wrote: On 03/12/2012 03:10 PM, Polytropon wrote: /etc/shells to work, but a passwd entry like bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe I think this would not let the user to login,etc I'm not sure... I assume logging in is handled by /usr/bin/login, and control is then (i. e. after successful login) transferred to the login shell, which is the program specified in the "shell" field (see "man 5 passwd") of /etc/passwd. How is login supposed to know if the program specified in this field is actually a dialog shell? From "man 1 login" I read that many shells have a built-in login command, but /usr/bin/login is the system's default binary for this purpose if the "shell" (quotes deserved if it is an editor as shown in my assumption) has no capability of performing a login. Now i gotta try this out. Off to hosed my system. If other configuration is set up right (e.g. /etc/shells), you can name *any* executable as the 'shell' field in /etc/passwd, and have it work. "Long, long, ago", I used this for client 'on demand' system back-up. They just put the tape in the drive, and logged in as the 'backup' user. *HOWEVER* this is -not- a solution for the OP's "problem", as a skilled, _malicious_, user can change, say, vi(1)'s idea of what executable it should invoke when a '!', or '!!' command is issued. I tried it out of curiosity to see if it was possible to login in joe, by the way the OS was configure. However my knowledge is not advance to continue, got stock on the message cannot not find "*-joerc" :-) Regards Ed ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On Mon, Mar 12, 2012 at 03:20:57PM -0500, Tim Daneliuk wrote: > > On 03/12/2012 03:13 PM, Thomas Dickey wrote: > >On Mon, Mar 12, 2012 at 02:19:06PM -0500, Tim Daneliuk wrote: > >>I have a situation where I need to provide people with the ability to edit > >>files. However, under no circumstances do I want them to be able to exit > >>to the shell. The client in question has strong (and unyielding) InfoSec > >>requirements in this regard. > >> > >>So ... are there editors without this feature? Can I compile something > >>like > >>joe or vi to inhibit this feature? > > > >man vi (see "-S") > > > > It turns out you can still work around this if your know the trick. > I am still researching this, but restricted vi appears to be compromised. > > Have you tried restricted vim? $ vim -Z :help restricted Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html pgpqkXozuNJ90.pgp Description: PGP signature
Re: Editor With NO Shell Access?
> From owner-freebsd-questi...@freebsd.org Mon Mar 12 17:46:04 2012 > Date: Mon, 12 Mar 2012 15:47:59 -0700 > From: "Edward M." > To: Polytropon > Cc: freebsd-questions@freebsd.org > Subject: Re: Editor With NO Shell Access? > > On 03/12/2012 03:23 PM, Polytropon wrote: > > On Mon, 12 Mar 2012 15:19:51 -0700, Edward M. wrote: > >> On 03/12/2012 03:10 PM, Polytropon wrote: > >>> /etc/shells to work, but a passwd entry like > >>> > >>> bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe > >> > >> I think this would not let the user to login,etc > > I'm not sure... I assume logging in is handled by /usr/bin/login, > > and control is then (i. e. after successful login) transferred > > to the login shell, which is the program specified in the > > "shell" field (see "man 5 passwd") of /etc/passwd. How is > > login supposed to know if the program specified in this > > field is actually a dialog shell? > > > > From "man 1 login" I read that many shells have a built-in > > login command, but /usr/bin/login is the system's default > > binary for this purpose if the "shell" (quotes deserved if > > it is an editor as shown in my assumption) has no capability > > of performing a login. > > > > > > > Now i gotta try this out. Off to > hosed my system. If other configuration is set up right (e.g. /etc/shells), you can name *any* executable as the 'shell' field in /etc/passwd, and have it work. "Long, long, ago", I used this for client 'on demand' system back-up. They just put the tape in the drive, and logged in as the 'backup' user. *HOWEVER* this is -not- a solution for the OP's "problem", as a skilled, _malicious_, user can change, say, vi(1)'s idea of what executable it should invoke when a '!', or '!!' command is issued. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
There are two edits to make to ex_shell.c in /usr/src/contrib/nvi/ex that will prevent a shell from being executed. 99,100c return (1); . 48,51c return (1); . On Mon, Mar 12, 2012 at 4:59 PM, David Brodbeck wrote: > On Mon, Mar 12, 2012 at 7:19 PM, Tim Daneliuk > wrote: > > I have a situation where I need to provide people with the ability to > edit > > files. However, under no circumstances do I want them to be able to exit > > to the shell. The client in question has strong (and unyielding) > InfoSec > > requirements in this regard. > > I vaguely recall that pico can be configured to work this way. Check > out /usr/ports/editors/pico-alpine. Sorry I can't give much more > help; it's been a very long time since I worked with that particular > editor. > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscr...@freebsd.org" > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On Mon, 12 Mar 2012 16:34:18 -0700, Edward M. wrote: > On 03/12/2012 03:47 PM, Edward M. wrote: > > On 03/12/2012 03:23 PM, Polytropon wrote: > >> On Mon, 12 Mar 2012 15:19:51 -0700, Edward M. wrote: > >>> On 03/12/2012 03:10 PM, Polytropon wrote: > /etc/shells to work, but a passwd entry like > > bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe > >>> > >>> I think this would not let the user to login,etc > >> I'm not sure... I assume logging in is handled by /usr/bin/login, > >> and control is then (i. e. after successful login) transferred > >> to the login shell, which is the program specified in the > >> "shell" field (see "man 5 passwd") of /etc/passwd. How is > >> login supposed to know if the program specified in this > >> field is actually a dialog shell? > >> > >> From "man 1 login" I read that many shells have a built-in > >> login command, but /usr/bin/login is the system's default > >> binary for this purpose if the "shell" (quotes deserved if > >> it is an editor as shown in my assumption) has no capability > >> of performing a login. > >> > >> > >> > >Now i gotta try this out. Off to > >hosed my system. > Does not work. Could not login, it shows "Couldn't open *-joerc." Very strange message. I know there's a .joerc in ~ (for the user) and a global /usr/local/etc/joe/rjoerc (for system-wide use). I also get this message: Couldn't open '*-joerc' Maybe this is because joe isn't a shell and doesn't set some required variables, such as $PATH or $HOME, and joe cannot find its rc files... The reason is what I see in /usr/ports/editors/joe/work/joe-3.7/main.c line 353 and above. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On Mon, Mar 12, 2012 at 7:19 PM, Tim Daneliuk wrote: > I have a situation where I need to provide people with the ability to edit > files. However, under no circumstances do I want them to be able to exit > to the shell. The client in question has strong (and unyielding) InfoSec > requirements in this regard. I vaguely recall that pico can be configured to work this way. Check out /usr/ports/editors/pico-alpine. Sorry I can't give much more help; it's been a very long time since I worked with that particular editor. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On 03/12/2012 03:47 PM, Edward M. wrote: On 03/12/2012 03:23 PM, Polytropon wrote: On Mon, 12 Mar 2012 15:19:51 -0700, Edward M. wrote: On 03/12/2012 03:10 PM, Polytropon wrote: /etc/shells to work, but a passwd entry like bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe I think this would not let the user to login,etc I'm not sure... I assume logging in is handled by /usr/bin/login, and control is then (i. e. after successful login) transferred to the login shell, which is the program specified in the "shell" field (see "man 5 passwd") of /etc/passwd. How is login supposed to know if the program specified in this field is actually a dialog shell? From "man 1 login" I read that many shells have a built-in login command, but /usr/bin/login is the system's default binary for this purpose if the "shell" (quotes deserved if it is an editor as shown in my assumption) has no capability of performing a login. Now i gotta try this out. Off to hosed my system. Does not work. Could not login, it shows "Couldn't open *-joerc." ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On 03/12/2012 03:23 PM, Polytropon wrote: On Mon, 12 Mar 2012 15:19:51 -0700, Edward M. wrote: On 03/12/2012 03:10 PM, Polytropon wrote: /etc/shells to work, but a passwd entry like bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe I think this would not let the user to login,etc I'm not sure... I assume logging in is handled by /usr/bin/login, and control is then (i. e. after successful login) transferred to the login shell, which is the program specified in the "shell" field (see "man 5 passwd") of /etc/passwd. How is login supposed to know if the program specified in this field is actually a dialog shell? From "man 1 login" I read that many shells have a built-in login command, but /usr/bin/login is the system's default binary for this purpose if the "shell" (quotes deserved if it is an editor as shown in my assumption) has no capability of performing a login. Now i gotta try this out. Off to hosed my system. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On Mon, 12 Mar 2012 15:19:51 -0700, Edward M. wrote: > On 03/12/2012 03:10 PM, Polytropon wrote: > > /etc/shells to work, but a passwd entry like > > > > bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe > > >I think this would not let the user to login,etc I'm not sure... I assume logging in is handled by /usr/bin/login, and control is then (i. e. after successful login) transferred to the login shell, which is the program specified in the "shell" field (see "man 5 passwd") of /etc/passwd. How is login supposed to know if the program specified in this field is actually a dialog shell? >From "man 1 login" I read that many shells have a built-in login command, but /usr/bin/login is the system's default binary for this purpose if the "shell" (quotes deserved if it is an editor as shown in my assumption) has no capability of performing a login. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On 03/12/2012 03:10 PM, Polytropon wrote: /etc/shells to work, but a passwd entry like bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe I think this would not let the user to login,etc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On Mon, 12 Mar 2012 17:40:10 -0400, Steve Bertrand wrote: > You can force a user directly into an editor so they have no shell > access. For example, if the user has '/bin/csh' as their login shell, > adding: > > exec /usr/local/bin/vim > > into their ~/.cshrc file will force them directly into vim. When they > exit vim, they are immediately logged off. Just an idea about extending this idea: What if the shell field for that user does not contain a shell, but the name of the editor instead? I assume it has to be "noted" in /etc/shells to work, but a passwd entry like bob:*:1234:1234:Two-loop-Bob:/home/bob:/usr/local/bin/joe could work (haven't tested that). A list of the files can be obtained when opening a file ^KE and pressing the Tab key. It would be worth testing if shell escapes like !command will work in this constellation... -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On 2012-03-12 15:19, Tim Daneliuk wrote: I have a situation where I need to provide people with the ability to edit files. However, under no circumstances do I want them to be able to exit to the shell. The client in question has strong (and unyielding) InfoSec requirements in this regard. So ... are there editors without this feature? Can I compile something like joe or vi to inhibit this feature? I don't know if this will help, but it may provide an idea that could spark something further. You can force a user directly into an editor so they have no shell access. For example, if the user has '/bin/csh' as their login shell, adding: exec /usr/local/bin/vim into their ~/.cshrc file will force them directly into vim. When they exit vim, they are immediately logged off. However, I don't believe this will provide them any way to see their files though. vim's ":open filename" and ":w filename" still work, but shell commands (eg ":! ls -la") don't. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
> From owner-freebsd-questi...@freebsd.org Mon Mar 12 14:22:29 2012 > Date: Mon, 12 Mar 2012 14:19:06 -0500 > From: Tim Daneliuk > To: FreeBSD Mailing List > Subject: Editor With NO Shell Access? > > I have a situation where I need to provide people with the ability to edit > files. However, under no circumstances do I want them to be able to exit > to the shell. The client in question has strong (and unyielding) InfoSec > requirements in this regard. > > So ... are there editors without this feature? Can I compile something like > joe or vi to inhibit this feature? If the need is for 'simple'/'minimal' editing -- as opposed to, say, regex- based global-search-and-replace, A more-or-less 'easy' way to do this could be to use a web browser. .htaccess to determine who can access what file, probably from a specific list. a cgi-bin that, on validate access, loads the file into a 'textarea' on a . (form has a 'hidden' field that identifies the file being edited, User makes changes in the 'text' block, clicks 'update' (form 'submit' button) when finished. There's a .htaccess on the form-processing cgi-bin to re-validate the submission. (prevents somebody 'faking' a file update without actual permission.) The cgi-bin then re-writes the edited file. Depending on 'security' requirements, you may need a shared-memory cache -- used between the two cgi-bin invocations -- to provide 'session' locking, prevent 'overlapping' updates, and trap _all_ 'forged' file updates. This has some 'maintainablity' advantages over the 'hacked' editor approach. It's much clearer to a future person just _what_ is going on. It's also clear to the user what they can, and _cannot_ do. This has major beneficial effect on those who attempt to 'push the limits'. Hack the editor to disable functionality, and _somebody_ *will* complain that they =need= that functionality, for a 'superficially plausable' reason. Otherwise, hacking the source code for, say, 'vi', should -not- be very difficult. Look for the logic that processes '!!' or ":!" at the beginning of an input sequence, and disable the related functionality. You could probably make a dinky little library -- with 'fake' routines for 'fork', 'exec', and 'pipe'; routes that 'do nothing' other than raise a security alert, and include that in the compile/link for a customized 'vi', before 'libc'. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On 03/12/2012 03:13 PM, Thomas Dickey wrote: On Mon, Mar 12, 2012 at 02:19:06PM -0500, Tim Daneliuk wrote: I have a situation where I need to provide people with the ability to edit files. However, under no circumstances do I want them to be able to exit to the shell. The client in question has strong (and unyielding) InfoSec requirements in this regard. So ... are there editors without this feature? Can I compile something like joe or vi to inhibit this feature? man vi (see "-S") It turns out you can still work around this if your know the trick. I am still researching this, but restricted vi appears to be compromised. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Editor With NO Shell Access?
On Mon, Mar 12, 2012 at 02:19:06PM -0500, Tim Daneliuk wrote: > I have a situation where I need to provide people with the ability to edit > files. However, under no circumstances do I want them to be able to exit > to the shell. The client in question has strong (and unyielding) InfoSec > requirements in this regard. > > So ... are there editors without this feature? Can I compile something like > joe or vi to inhibit this feature? man vi (see "-S") -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpJTSE7KtVaE.pgp Description: PGP signature
