On 16.12.2006 01:10, Crispin Cowan wrote:

Boyan Tabakov wrote:

...

Hi, Is it possible to restrict certain users to executing only one specific command on the server with ssh? No interactive login should be allowed and no other commands should be accepted. If possible - how? Didn't see any options in sshd_config that looked promising... One think that came to mind is using the shell field in the /etc/passwd file (setting it to some custom script). Any other ideas?

You could do that, but the security is poor: you are depending on the security of the application that you give the user. For instance, if you give the user vi, then the user can just "shell out" with ":!bash"

That confined shell technique that I posted on December 10 <http://lists.opensuse.org/opensuse-security/2006-12/msg00004.html> also works here. My old post described how to confine a user's shell, so that they can only execute some commands. To use this technique to allow them only a single command, you would instead use a hardlink pointing from a unique name for your command (say, /usr/bin/restrictedgrep -> /usr/bin/grep ) and then use the rest of the technique that I outlined to build your profile for /usr/bin/restrictedgrep.

Under this scheme, if the user tries to shell out, or in fact access any file you did not give them access to, AppArmor will block it.

Crispin

Thanks! I'll check this out. -- Blade hails you... All the same take me away We're dead to the world --Nightwish

On 16.12.2006 16:56, Martti Laaksonen wrote:

You might want to look into using public keys for user authentication and setting some options to a specific key(s) in ~/.ssh/ authorized_keys file.

There's more info in sshd's man page (paragraph Authorized_keys file format), but basically you can restrict a specific public key to execute only a certain command by placing command="command_name" option before the public key data in the authorized_keys file.

Thank you too! This sounds like the thing I need exactly. I am currently doing the same by a bash script, set as the default user's shell that checkes if the command is the one I allow. But this is already build-in, so I'll switch to it! Thanks... -- Blade hails you... Farewell - no words to say Beside the cross on your grave And those forever burning candles --Nightwish

On 18.12.2006 01:27, Crispin Cowan wrote:

Martti Laaksonen wrote:

...

You might want to look into using public keys for user authentication and setting some options to a specific key(s) in ~/.ssh/authorized_keys file.

There's more info in sshd's man page (paragraph Authorized_keys file format), but basically you can restrict a specific public key to execute only a certain command by placing command="command_name" option before the public key data in the authorized_keys file.

Martti's suggestion and mine work very well together. The above enforces that a user ssh'ing into the machine can only run a single command, and my suggestion gives you mandatory policy control over what that command can do. Using the hardlink hack, you can make the command unique to a user, or generic to a role.

True! These techniques combined offer great flexibility that does not sacrifice security. In my particular case, however, the command being executed should not be subject to 'twisting' of its normal behavior. Also, AppArmor is not around when you don't have SuSE... -- Blade hails you... One night I dreamt a white rose withering a newborn drowning a lifetime loneliness I dreamt all my future. Relived my past And witnessed the beauty of the beast --Nightwish

On 18.12.2006 11:14, Crispin Cowan wrote:

Boyan Tabakov wrote:

...

True! These techniques combined offer great flexibility that does not sacrifice security. In my particular case, however, the command being executed should not be subject to 'twisting' of its normal behavior.

What is the command? Or is it privately developed? Or secret?

If privately developed, you are assuming that your developers write perfect code.

If it is just secret to not give attackers a head start, well, ok, because "security through obscurity", while lame, actually does work on an ad hoc one-shot basis. It just falls apart when scaled up to where everyone uses it.

...

Also, AppArmor is not around when you don't have SuSE...

AppArmor ports are available for Slackware, Ubuntu, Gentoo, and Pardus Linux. I would love to have ports & maintainers for other distros as well, precisely so that you can use AppArmor any where you want. Ports are especially needed for Debian proper (should be an easy port from Ubuntu or Gentoo) and Red Hat. Which distro were you needing it on?

Crispin

Sorry... no - the command is not secret, nor private (security through obscurity is something I try not to employ). I just asked the question in general. In this specific case the command is 'svnserve -t -r /path/to/repo' with the svnserve setuid to a user that has write access only to the repository files and nowhere else. I see now that I should have said this in the beginning, so that it could be taken into account. Yet again, I was interested in a general solution that could help me elsewhere in the future. About AppArmor... I an not having in mind particular distro. I am currently using SuSE. Although AppArmor might get ported for other distros too, I think a good trick would be something that does not rely on much more than the tools used for the immediate action (e.g. sshd and svnserve in my case). That's why I prefer the authorized_keys one. Thank to both of you for giving me different perspectives. 'There is more than one way to do it!' -- Blade hails you... Bury my dreams dig up my sorrows Oh Lord why The angels fall first? --Nightwish