Hello, I find out that there is a way from putty to pass a command to your shell when trying to log in to a server and bypass .profile. Actually you can do this if you open a bash shell. The command to bypass .profile is the following:
ssh -t hostname "bash --noprofile"
Is there a way to disable this option? I mean not to allow a user to bypass his .profile even when he runs this command. Thank you in advance
e.g.:
# cat >>/etc/ssh/sshd_config
Match User a_very_smart_user
ForceCommand /sbin/nologin
# refresh -s sshd
This seems a little harsh to stop someone logging in at all. Perhaps use the ForceCommand to run the profile instead.
Robin
Hi,
You could write a wrapper script which removes the specific option but this can have a impact to other applications.
Something like:
mv /bin/bash /bin/bash.orig
cat /bin/bash
#!/bin/bash
exec /bin/bash.orig `echo "$@" | sed 's/--noprofile//g'`
Be carefull, not testet in detail!
Regards
A script such as that can easily be parsed to quickly find that this can be bypassed with
ssh -t hostname "bash.orig --noprofile"
Perhaps a combination for the ForceCommand and your own script would do the trick. I have something like this in place to prevent unauthorised sftp connections by users. I'm not sure how robust it is, but it seems to placate the auditors 
I match on an OS group. There is a daily job to rebuild the group from a simple text file that our security admin team manage. It's a simple list of all users excluding those in the allowed list. If you are in the denial group, no sftp connection is allowed. Of course it doesn't prevent outgoing sftp :rolleyes:
Robin
It's the user's profile. How are you going to stop them from modifying it even if you come up with a way they can't bypass it?
---------- Post updated at 03:08 PM ---------- Previous update was at 03:05 PM ----------
Or even
bash.orig -login
Or, heaven forbid,
. .profile
IF you have code users must run on login, consider /etc/profile :
Create a special script in a directory the user cannot change, maybe something like this
if [ $(id -g) -eq 3000 ] ; then # users in just this group
. /path/to/special/script.sh
fi
Place the above in /etc/profile . It sounds like you have required stuff (probably security) that users are going to try to evade. Do not put stuff like that in .profile Users can and will mess with it.
If you really have security problems consider a restricted shell for some users.
You are right. I guess the realy safe way is removing this option from bash through modifying the source code and building a custom version.
'{ "noprofile", Int, &no_profile, (char **)0x0 },' through ' /* { "noprofile", Int, &no_profile, (char **)0x0 }, */' ./configure
make
test it:
./bash --noprofile
./bash: --noprofile: invalid option
Usage: ./bash [GNU long option] [option] ...
./bash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--norc
--posix
--rcfile
--restricted
--verbose
--version
Shell options:
-ilrsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option
# make a backup from your original bash bevor replacing them ;)
cp bash /bin/bash
Regards
---------- Post updated at 22:56 ---------- Previous update was at 22:51 ----------
I guess this will not help in this case...
man bash
--noprofile
Do not read either the system-wide startup file /etc/profile or any of the personal initialization files ~/.bash_profile, ~/.bash_login, or ~/.profile. By default, bash reads these files when it is invoked as
a login shell (see INVOCATION below).
Regards
thank you all guys for your responses. @achenle: well actually they cannot change their profile if they connect to the server because their profile runs an application. so when the users connect to the server they look directly to the logon screen of the application that they are going to connect. they dont go to command line. thats why they used this command through putty in order to get command line. @XrAy: your last suggestion seems good to me. i will try that. @agent.kgb, rbatte1: in /etc/ssh/sshd_config file i cannot find the lines that you mentioned. i have to insert these lines by myself? does it matter in which section i will enter these lines or i can put them at the end of file?
You still have to stop them using ftp, sftp, scp, etc. as they you remotely modify it and replace the version you have created.
If it is a common thing that you want them all to run, I'd follow the suggestion from Jim and put something in /etc/profile instead.
If you don't want everyone to run it, then have it conditional on the primary group or some other external reference that you can easily adjust. We have the following in ours:-
GROUP=`id -gn`
if [ -f /usr/local/bin/${GROUP}.start ]
then
. /usr/local/bin/${GROUP}.start
fi
I hope that this helps,
Robin
well ftp is disabled on the server but i guess they can connect through sftp and scp you are right. it doesnt hurt though if i apply both suggestions (modify sshd_config, bash) and try also this with /etc/profile. it will be more complex though with /etc/profile cause not all users connect to same database. its the same logic in all their profiles but each one connects to different database. so i have to break it down in a lot of pieces. i think i will apply one thing at a time. first i will enter the lines in sshd_config and make sure that i dont have any problem with ssh. then i can change bash to remove the option of "--noprofile". then is the /etc/profile suggestion which will take more time to do so i will do it last. i think if i apply all 3 then probably they will not be able to mess around
just put them at the end and restart sshd. if your users should run only one application, use "normal" shell ksh for users, which doesn't have such options, and way better - use rksh (restricted version of ksh), set the PATH correctly in profile, make their .profile files owned by root and only readable by users.
Your code called from /etc/profile could always have a reference table to look up who is meant to connect to which database in some way. Something like:-
$ cat /etc/dbusers
Robin DB1
Don DB2
Jim DB1
You could then read it something like:-
grep "^`id -un` " /etc/dbusers | read x DB
Notice that there is a trailing space before the closing quote in case you have user names like bob , bob2 etc.
Would that help?
Robin
thank you guys. your thoughts are really helpful. @agent.kgb: its a good idea to change the permissions of the users profile. users shell is already ksh. the problem is that they could call bash shell with --noprofile option through putty. their default shell is ksh. anyway "normally" they never enter command line because when they log in they run straight away the application which connects them to database and when they exit database all their connection shells are exiting.
Three things I have learned by painful experience:-
The list goes on, but these are applicable to your concerns.
Robin
SCO Is vulnerable to this also.
I have two questions.
Won't work.
The user owns the directory and can just delete or rename the root-owned .profile and then create their own.
I worked one place that tried that to prevent the use of a ".rhost" file. They created root-owned .rhost directories in everyone's home directory and IIRC set the setgid bit, making it impossible to delete.
Solution?
mv .rhost .rhost.I_CAN_NAME_ANYTHING_IN_THIS_DIRECTORY_ANYTHING_I_WANT
Then I created an .rhost file just to prove my point.
If the user owns their home directory, they own everything in it and under it.
rbatte1 you are totally right! I experience the same thing a lot of times. It actually makes me angry the fact that the simpler that you are trying to make something to other people the mistakes that are done are more and more "childish". @jgt: im not 100% sure about this but i think is the same way that it find all the other shells (ksh, rksh,etc). through the environment library. if you check the location /usr/bin probably you will find all shells that you can use.
I did a little experiment and set up a user with a restricted ksh shell. I found that using the "bash --noprofile" option did not allow the user to log in; the remote session hangs after accepting the password.
Sftp also failed.
For users that are only allowed sftp access, I use MySecureShell; it does not allow login attempts either.