I have modified versions of certain internal/external commands that I am putting into some directory say /mydir.
All the users will go an authentication check once they log in and based on the outcome there are two possibilities:
User passes authentication - No action required.
User fails authentication - Any command user executes will be looked upon in /mydir first and if modified version of the command is available there it is
executed else normal command will be executed.
I have taken a simple logical approach to achieve this. Change PATH to PATH=/mydir:$PATH from within /etc/profile. Now I want to restrict the users to
revert back to original path. Is there any way to do this?
Also ideally I don't want users to view this modified PATH and allow them to change the PATH but the change should not take place.
Basically I want to achieve something like this:
User logs in - PATH gets changed to new PATH - User issues PATH command - Original PATH is displayed even though actually PATH is changed and new PATH is
in effect.
2. User tries to change PATH - PATH command is executed - user issues �echo $PATH� to verify - he gets modified PATH displayed but actually PATH is not
changed.
I summary I want to change user's PATH but don't want him to know that this has happened.
Is this possible? Ideally I want to achieve what I have described but if it is not at all possible then at least I want to restrict user from executing
PATH command.
Any ideas?
Thanks in advance and look forward know your thoughts on this.
Why do you want to do it this way? It seems like a dishonest way to deal with your users, in my opinion. Why not simply deny them access if they fail authentication?
This is my client's requirement so I cannot question him why he want to do this, I simply have to provide the solution as long as it is not crime by law so it would be better we discuss this purely in technical terms rather than debating if it's appropriate or not.
I am thinking of achieving this by trapping the signal for ENTER (RETURN) key so that I can monitor each command entered by the user and handle them inside my script. I this way when user enters PATH command my script will trigger and handle it inside the script.
Now question is whether there is better way to do this? and How do I TRAP ENTER or RETURN key. Is that possible?
---------- Post updated at 11:59 AM ---------- Previous update was at 11:43 AM ----------
Also this is not just the question of denying them access. The users should not be able to change PATH and defeat our purpose for changing their PATH. This is the main requirement (fooling the user is secondary and if that is achieved it will be bonus).
If you've got ksh available, you could try set up an restricted environment. Quote from the man page:
Rksh is used to set up login names and execution environments whose
capabilities are more controlled than those of the standard shell. The
actions of rksh are identical to those of ksh, except that the follow-
ing are disallowed:
Unsetting the restricted option.
changing directory (see cd(1)),
setting or unsetting the value or attributes of SHELL, ENV,
FPATH, or PATH,
specifying path or command names containing /,
redirecting output (>, >|, <>, and >>).
adding or deleting built-in commands.
using command -p to invoke a command.
Another way that I can think of would be:
Copy the checked commands to an alternative directory
Replace the original with (a) shell script(s) which, depending on the authentication state, runs either the original command or the file from /mybin
That way there wouldn't be a need to modify / prevent modification of the PATH variable.
Manipulating the PATH won't do the trick expected by your client, I'm afraid, as any user experienced enough to tinker with this variable could simply use 'which' to get an idea of what tools he's supposed to work with, then prepend the absolute path to the tool in question in order to bypass your preselection ... at least, that's what the ordinary user in me would do to begin with
pludi: I have given a thought on using restricted shell (rbash) but I just want to restrict user doing few things like not allowing him changing PATH etc. I am checking if it is possible to set up rbash and customize it, I mean if I can set up rbash allowing certain things and restricting other.
dr.house: You have a good point that user can use "which" command. I am checking all these possibilities and also alternate ways to achieve this if this is not the proper way.
Your thoughts on this would be really helpful so please keep on sharing, I will also share what I am up to.
What may or may not keep the unaware at bay (- as all others would revert to 'find', 'export' and the like as need be ...): update '/etc/profile' and '/etc/bashrc' (or the like) with functions, variables and aliases to create an environment based on the current user's status, then replace '/home/[user]/.profile' and '/home/[user]/.bashrc' by links to the system-wide, "root-write only" configuration files - and hope for the best (as, of course, any such manipulation will be transparent to those able to read ... this is Linux, after all).
On the long run (not least of yours away from the users figuring out what you've done ...), however, chroot or even SELinux might become increasingly attractive to you and your client, respectively
dr.house, as you said there can be "n" number of possibilities the user can find out that he is being manipulated so I am thinking dropping this idea of making all this transparent to user. Let user know it. My goal is now to "execute a clone commands from /mydir if available else execute from normal system path" (if user fails authentication). If I use changing user PATH approach inside a script then my problem boils down to just make sure user is restricted to changing PATH. Now the only question remains is "how to restrict unauthenticated user change his PATH?", otherwise there is no difference between authenticated Vs unauthenticated user.
Will try implementing strategies you have suggested. chroot is out of question as it would require a lot of set up in terms of copying the binaries and other things from "real root" to new root. SELinux, not given a thought yet. But as now problem reduced to just restricting user of changing PATH these options may not be appropriate.
Agreed, so do you think it is NOT possible to restrict user from changing PATH?
I was thinking of exploring this possibility but if it is at all not possible then may be I can direct my thoughts towards finding alternate ways rather than considering this solution. Please comment.
so it would be better we discuss this purely in technical terms rather than debating if it's appropriate or not.
