This is a idea for a security. Our employees shall have access to some commands on a linux server but not all. They shall e.g. have the possibility to access a log file (less logfile) or start different commands (shutdown.sh / run.sh).

Background information:

All employees access the server with the same user name: Our product runs with "normal" user permissions, no "installation" is needed. Just unzip it in your user dir and run it. We manage several servers where our application is "installed". On every machine there is a user johndoe. Our employees sometimes need access to the application on command line to access and check log files or to restart the application by hand. Only some people shall have full command line access.

We are using ppk authentication on the server.

It would be great if employee1 can only access the logfile and employee2 can also do X etc...

Solution:
As a solution I'll use the command option as stated in the accepted answer. I'll make my own little shell script that will be the only file that can be executed for some employees. The script will offer several commands that can be executed, but no others. I'll use the following parameters in authorized_keys from as stated here:

@Vinko, @PEZ: I've added some background informations. Instead of saying "stupid idea" you could provide comments with value. What is in your opinion a better idea?
– MarcelDec 31 '08 at 11:28

8

I still don't see any excuse on having multiple users share the same username.
– EldelshellDec 31 '08 at 11:38

2

"My own little shell script"? It sounds quite dangerous. Unless you're an expert, there are probably many ways to escape from it to the full shell. I would rather trust a well-written, debugged and maintained program (several have been mentioned).
– bortzmeyerJan 5 '09 at 13:00

ssh follows the rsh tradition by using the user's shell program from the password file to execute commands.

This means that we can solve this without involving ssh configuration in any way.

If you don't want the user to be able to have shell access, then simply replace that user's shell with a script. If you look in /etc/passwd you will see that there is a field which assigns a shell command interpreter to each user. The script is used as the shell both for their interactive login ssh user@host as well as for commands ssh user@host command arg ....

Here is an example. I created a user foo whose shell is a script. The script prints the message my arguments are: followed by its arguments (each on a separate line and in angle brackets) and terminates. In the log in case, there are no arguments. Here is what happens:

Our "shell" receives a -c style invocation, with the entire command as one argument, just the same way that /bin/sh would receive it.

So as you can see, what we can do now is develop the script further so that it recognizes the case when it has been invoked with a -c argument, and then parses the string (say by pattern matching). Those strings which are allowed can be passed to the real shell by recursively invoking /bin/bash -c <string>. The reject case can print an error message and terminate (including the case when -c is missing).

You have to be careful how you write this. I recommend writing only positive matches which allow only very specific things, and disallow everything else.

Note: if you are root, you can still log into this account by overriding the shell in the su command, like this su -s /bin/bash foo. (Substitute shell of choice.) Non-root cannot do this.

Here is an example script: restrict the user into only using ssh for git access to repositories under /git.

Of course, we are trusting that these Git programs git-upload-pack and git-receive-pack don't have holes or escape hatches that will give users access to the system.

That is inherent in this kind of restriction scheme. The user is authenticated to execute code in a certain security domain, and we are kludging in a restriction to limit that domain to a subdomain. For instance if you allow a user to run the vim command on a specific file to edit it, the user can just get a shell with :!sh[Enter].

Seriously, this is VERY DANGEROUS. What will stop me from executing git-receive-pack '/git/';dd if=/dev/urandom of=/dev/sda?
– YetiJul 29 '17 at 16:46

@Yeti Do we have a command injection hole here? That needs to be addressed. Also, the abuse of file patterns that I perpetrated in the case doesn't look correct to me.
– KazJul 29 '17 at 21:07

1

Yes, /bin/bash -c "$2" is insecure (similar to how SQL injection works). You could filter the string with "magic quotes" like PHP. But the easy way to absolutely ensure security is to call a command manually and then pass the parameters within double quotes. Because the security of the whole thing then depends on that command being the weakest link (harder to verify). Most interesting to see how your answer has 22 upvotes, but nobody noticed this ;) Will you update your own answer?
– YetiJul 29 '17 at 21:14

@Yeti Yes; I just did. I replaced the script with one which breaks the -c argument with set and then takes only the first two words from it. The first must be an allowed git- command, and the second must be a path which is canonicalized, checked against the allowed prefix and also checked for existence. Can you think of any way to break this?
– KazJul 29 '17 at 21:29

Unless someone creates an alias (or overrides a command) for any of the given commands, then no, Bash double quotes should be safe (and if not, then this is a bug in Bash).
– YetiJul 29 '17 at 22:09

What you are looking for is called Restricted Shell. Bash provides such a mode in which users can only execute commands present in their home directories (and they cannot move to other directories), which might be good enough for you.

What if the user does "!/bin/sh" or some such from the less prompt?
– PEZDec 31 '08 at 11:02

3

@Ubersoldat: Please grow up and tone down the aggression in all your posts. He was asking whether the restriction only applies to bash or child processes too (and to answer his question, it turns out it doesn't).
– user42092Dec 31 '08 at 22:30

A major problem with restricted shell is that to secure it, you must use .profile or .bashrc to restrict the PATH, disable builtins, etc., but those files are only invoked for interactive shells. If a user uses ssh to run a remote command they are not invoked. This allows a user with ssh access to an account with SHELL=/bin/rbash to just do something like "ssh remotehost bash" to get a non-interactive but unrestricted shell. You need SSH forced commands as HD suggested, but this can protect against shell escapes as PEZ asked (once PATH is locked down - it includes /bin:/usr/bin by default).
– Alex DupuyNov 11 '11 at 18:58

1

I take that back, bash will invoke .bashrc (not .profile) when running non-interactively under sshd; however, you have to make sure that you set PATH explicitly and disable builtins and aliases in .bashrc - changing to a subdirectory not in/above PATH or .ssh/ or .bashrc is also a good idea. Having any command that can write to arbitrary files will create a problem - these are not always obvious, e.g. sed 'w' command could be used to overwrite .bashrc and break out. A chroot jail will always be safer if you can use it, and ssh forced commands will be more restricted.
– Alex DupuyNov 11 '11 at 20:17

You can follow the restriction guides mentioned above, they're all rather self-explanatory, and simple to follow. Understand the terms `chroot jail', and how to effectively implement sshd/terminal configurations, and so on.

Being as most of your users access your terminals via sshd, you should also probably look into sshd_conifg, the SSH daemon configuration file, to apply certain restrictions via SSH. Be careful, however. Understand properly what you try to implement, for the ramifications of incorrect configurations are probably rather dire.

Note that pizzashack.org/rssh is an excellent (possibly the best) solution for the special case where you want to allow scp/sftp/rdist/rsync/cvs (and don't need access to anything outside a chroot jail) - however, it does not solve the general question of the original poster, who wanted users to be able to view log files and run certain run/shutdown scripts.
– Alex DupuyNov 11 '11 at 18:45

All you have to do is set this executable as your login shell. For example, edit your /etc/passwd file, and replace your current login shell of that user /bin/bash with /root/rbash.sh.

This is just a simple example, but you can make it as advanced as you want, the idea is there. Be careful to not lock yourself out by changing login shell of your own and only user. And always test weird symbols and commands to see if it is actually secure.

You can test it with: su -s /root/rbash.sh.

Beware, make sure to match the whole command, and be careful with wildcards! Better exclude Bash-symbols such as ;, &, &&, ||, $, and backticks to be sure.

Depending on the freedom you give the user, it won't get much safer than this. I've found that often I only needed to make a user that has access to only a few relevant commands, and in that case this is really the better solution.
However, do you wish to give more freedom, a jail and permissions might be more appropriate. Mistakes are easily made, and only noticed when it's already too late.

I really liked this approach. Do you have any idea how can we handle multi-words commands like "service httpd restart"?
– FarzanMar 19 '18 at 23:23

1

@Farzan You can execute commands in a variable, e.g. ln="service httpd restart", with: ${ln[@]}. Still be sure to think about security issues, a whitelist for only alphanumeric characters and whitespaces would be useful in such a case. But you can also just do: if [[ "$ln" == "restart-httpd"];then service httpd restart;fi, and work with simple commands like that.
– YetiMar 20 '18 at 10:08

@Christian, did you add /root/rbash.sh to /etc/shells? It depends on the distribution. You can also try temporarily disabling selinux, and check log messages for clues (look at the timestamp) in files in /var/log.
– YetiMar 23 '18 at 8:32

Another way of looking at this is using POSIX ACLs, it needs to be supported by your file system, however you can have fine-grained tuning of all commands in linux the same way you have the same control on Windows (just without the nicer UI). link

chroot and jail are nice tools. But for my problem I don't think it is a solution. I don't want to hide other directories than the home dir, I want to restrict the access to files in the user home dir!
– MarcelJan 2 '09 at 10:00

3

@Zsolt, the above is not an actual answer, but links to answers. This should be avoided, as links inevitably go dead over time. It is alright to give references, but the meat of the answer should be right there in your own text.
– zrajmJan 26 '16 at 14:21