Hello,
I wrote a script and disabled Ctrl+C using
trap ' ' 2
For security, I cannot allow users to exit the script on their own for then they would have access to the command prompt. Are there any other cases that I need to cover?
Thank you. I'm new to scripting.
Do you know what rsh is? a Restricted shell. That is more secure than anything you will script.
Basic rsh information for Linux:
Restricted Shells
Also consider chroot jails if you have stringent security requirements.
How are your users logging in? What are they on the computer for?
If it's a desktop login, good luck stopping anyone who knows what he's doing from getting an interactive shell. I've never failed to be able to get an interactive shell from a desktop login no matter how "locked down" it supposedly was.
Restricted shells and chroot jails - as already mentioned - are just about your only options.
Also, I question the logic behind not allowing anyone to have an interactive shell. What are they going to be able to do with an interactive shell that they couldn't do anyway? What any user can learn from an arbitrary computer is defined by the system calls he has access to, and the files visible to him. The tools used to make those system calls and view those files are irrelevant. Thinking that removing access to an interactive shell improves security shows a lack of understanding regarding true security. That's like saying no one can have a 16 oz claw hammer when there are 20 oz ones readily available.
It is quite possible to specify a shell script (or other application program) as a login shell in /etc/passwd. Then, when that user logs in, all they get is access to that program. If they break out of that program; they're back to a login prompt. But, if the application program specified as the login shell has a shell escape mechanism, the system is theirs to play with as they see fit.
I would just like to link up to the chroot, it is available directly in openssh.
Simple directive in sshd_config will enable sftp chroot, and users or groups will be limited by it.
If you follow best practice it will be impossible to exit the jail.
As for scripts or profiles which limit user, there is alot of code to be written besides one trap and it hard to limit a savvy person (it is doable perhaps but the effort will be great.)
Perhaps, if you elaborate which is the exact requirement for that user to do on server, folks might help further.
Thank you everyone who responded, I'm going through in no particular order.
I would be very interested to do this:
"It is quite possible to specify a shell script (or other application program) as a login shell in /etc/passwd."
I need more information in order to follow up with it though. I tried googling the topic.
---------- Post updated at 05:29 PM ---------- Previous update was at 05:28 PM ----------
I do understand that I need to modify the permissions so that even if the user is to break out of the script, they cannot do anything I wouldn't want them to anyways.
Permissions aren't the issue (as long as your users can't modify the script you're letting them run). The whole point is that if they control-C out of the script, they fall back to a login prompt; not to a shell prompt.
What you have to be careful about is any interactive commands that you let your users access from your script. For instance, if you let them use ed , ex , sed , or vi to edit a file, they can get a shell escape from those editors to run anything they want (including an unrestricted shell). Some editors have an option to restrict the ability to do this, but these options are not standardized (so you need to check the man page for any editor you want to allow your users to use for an option such as -r or a command name like red or rvim that will start the editor you want your users to use in restricted mode on your system).
If you want to see a very simple example, create a new user with login name date with or without a password. Set the login shell for that user to the path to the date utility on your system (probably /bin/date or /usr/bin/date ). When someone logs in to your system using the login name date, they'll see the current date and immediately go back to a login prompt.
Just remember that since you didn't login with bash , or ksh , or some other normal shell, the initialization scripts those shells run when you login are not run. So, your script will need to initialize any environment variables it needs to run just like you need to do if you run a script from a cron job.