There is also an immutable file flag on some systems. 
As Jim Mcnamara mentioned above - In AIX /etc/profile is one of the files always processed during login - there is a lot that can be done there.
To get an understanding of what users are trying to do/use as default shell you could add something like
print $LOGNAME: `date`: `ps | grep $$` >/to/some/where
... to have a history of who, when, what shell.
Personally, I prefer to not use local .profiles at all. Too many headaches. Users do not 'own' their home directory - only sub-directories, so the admins can always control the content of $HOME/.profile if it even exists.
An additional thought - in some companies it is grounds for immediate dismissal to deliberately go against the company security configuration (showing it can be circumvented should be applauded, but helping others get past policy should not). Along those lines a banner, even though boring to click away - may provide some additional insight to the 'personal' impact of getting on the command line when that is not intended.
Short recap:
- Make use of /etc/environment and /etc/profile because everyone should pass through these (it is what documentation says iirc)
- Do not rely on $HOME/.profile - assume it is tainted
- If possible, have the system 'own' $HOME.
[quote=-=xray=-;302937118]
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.
- download your favourite bash version from Index of /gnu/bash
- modify the shell.c and replace the following line
'{ "noprofile", Int, &no_profile, (char **)0x0 },' through ' /* { "noprofile", Int, &no_profile, (char **)0x0 }, */' - build your custom version
./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 did the things that you suggested and it works perfectly now. the --noprofile option does not exist anymore and also when i tried to run the command that i said earlier the session closes as soon as i enter the password.
however i have some questions about the implementation of this new bash version that i created.
shall i just copy the bash command to my library directory or do i need to do something else first? i mean i need to uninstall bash and install it again? it does not effect the "whole bash package"?
So now your system requires a customized version of bash?
What are you going to do next time bash has a security vulnerability and gets upgraded?
This entire discussion just seems wrong to me. Why not just have users rlogin to this remote system and make their login shell on that system be the utility they are allowed to run. Why give them access to a shell on that system at all?
well actually it doesnt matter what kind of shell you assign to the users. thats why i started this discussion in the first place. for example the user that tried the command to connect to the server and get command line his shell is ksh. but through putty he has the ability to pass a command to the server and choose to run bash shell and use the --noprofile option. so even if i change the login shell of the user he can still do the same.
You seem to have missed what I suggested. Don't use putty and allow the user to choose the command they're going to run on the remote machine.
Have them rlogin to the remote machine and set up their login shell on that remote machine to be the program that you want to run (the program you want to put at the end of the .profile you don't want them to be able to change); not bash , not ksh , not sh ; just the program you want them to run on that machine.
As a simple solution i would keep the current package and just overwrite the orginal bash with your custom build, but keep in mind, that after a software update you may need to recopy your bash and you should keep your custom build up date for security reasons.
A more complex solution is to maintain your own bash package (rpm).
- Download a sample rpm-spec file for AIX from Perzl.org (e.g. bash-4.3-13.spec)
- write a custom spec-patch file which disable the option and add them to the bash spec file
- build
rpm -ba bash-*.specyour custom rpm
Regards
PS
Please validate the other suggestions (e.g from Don Cragun). Maybe manipulating the bash is to much for that what your need.
@Don Cragun: Unfortunately I cannot use rlogin because our security department said that rlogin contains security vulnerabilities which can be exploited so we had to disable the service from our servers. Anyway reading your last post I still think that this will not prevent users from doing what they tried to do before. Even if I remove putty from their PCs and give them a different tool to connect on server, nothing stops them from download putty and use it. and if they do that it doesn't matter what kind of shell they are using. Even if I set their initial shell to /bin/myscript as long as they have putty they can still execute remote ssh command and run bash with --noprofile option.
@XrAy: Thank you for your reply. well I'm actually testing all the suggestions that people posted here. this is what I said that I will do and this is what I'm doing right now. I didn't focus in just one thing. I'm trying to see what is the best solution to implement or even a combination of things. this is what I found until now:
- Obviously when I create a custom base version of bash solves the problem of remote execution of
--noprofilecommand. but as you said I have to be alert that every time I need to upgrade bash I need to have in mind that I will still exclude the --noprofile option. - ForceCommand is doing a great job on sshd_config. I find out that when I use this option it solves all the issues that I faced.
[list=a] - The user cannot execute the
bash --noprofileoption even with the original version of bash - The user cannot do sftp and ssh to server and get command line
- The user cannot use scp to send or receive files from server.
[/list] - I couldn't make /etc/profile modification work.
I test it for one user but it doesn't seem to work. The user can still execute the remote command he wants through putty and can connect through sftp and use scp also.
No. The user's shell - in your example ksh - is still used to run the command passed. Change a user's shell to "/bin/false" and see if you can still run arbitrary commands with that user via ssh.
Well if you set /bin/false as the initial shell for a user of course he will not login. The point is that the user can connect to the server through this shell but not get to command line. And before you mention anything about restricted shells I also tried it with rksh and the user can still bypass his .profile and get command line.
You're too fixated on preventing a user from "bypassing his .profile".
You can't stop that. And you can't control what's in a user's .profile in the first place.
And even if a user gets to a command line, he can't perform any operations he couldn't perform without command line access.
Operations on objects such as files or directories are done by system calls to the kernel. Whether they're allowed or not depends on the operation and the permissions given to that object for the user making the system call. WHERE that system call comes from is irrelevant. The kernel doesn't care if it comes from the bash or the boogersnot executable.
You can't really give someone a little bit of a login, although you can use a restricted shell to restrict things somewhat.
Well I think you are missing the point of the whole thread. These users existed on the system for a really long time and nobody has access to command line. NOBODY. They just login to the server and go straight to the application. They exit the application and their sessions is closed.
Recently we noticed that if a user uses putty to connect to the server he can run a remote command to the server and call bash shell (which is not their default shell) with --noprofile option. and in all these pages of the thread a lot of ideas came to the surface. In my previous posts I stressed the fact that I am trying to test what the people suggested in order to find out what suits my situation better, so creating a custom based version of bash obviously solves the specific problem but as you said and as XrAy said you need to be alerted every time you make upgrade of bash shell in order to remove this option from it and I also said that if you enter some lines in sshd_config file in order to force the execution of a specific command for a user or a group of users it works!
It doesn't work only for ssh login, it works also when the user tries to sftp or scp. So I guess that there is a way after all to prevent a user do what he wants to do. After all this should be the way. If you are the administrator then you should force your way to the users because if you allow them do whatever they want they would eventually do some stupid things that will create a mess for you to handle.