Prev: Fear about a WLAN card
Next: how to zero nfs counters
From: Ignoramus26563 on 3 Feb 2010 13:28
I have a user who needs me to do something for him in my linux account
automatically.

The action taken uses the IP of the connection and no other input

To that end, we set up an entry in authorized_keys:

command="/my/script.sh" ssh-dsa ... his key ...

In other words, his key is not a general purpose access key but is
only allowed to run /my/script.sh.

/my/script.sh script does various work, using only one input from $SSH_CLIENT:

>>> #!/bin/sh
>>> MY_IP=$(echo $SSH_CLIENT | awk '{print $1;}')
>>> DoSomethingWith $MY_IP
>>> DoSomethingElse $MY_IP

etc etc. The script does not use command line arguments, or any other
environment variables, besides ones used by bash, ld-preload etc. The
actions actually taken by a script include running other scripts,
etc.

I am concerned whether this is secure and whether this can be
subverted somehow, say by overriding environment variables.

I have a feeling that it is safe, and yet, I want to double check.

PermitUserEnvironment is not defined.

I believe that SSH_CLIENT is set by sshd and can never be anything
other than an IP address followed by two numbers. (ie it cannot be
"`rm -rf /`" or some such).

What I am concerned with is, say his account is hacked. Can a hacker
somehow elevate privileges based on my script and execute arbitrary
commands.

i
From: David Schwartz on 3 Feb 2010 17:16
On Feb 3, 10:28 am, Ignoramus26563 <ignoramus26...(a)NOSPAM.
26563.invalid> wrote:

> What I am concerned with is, say his account is hacked. Can a hacker
> somehow elevate privileges based on my script and execute arbitrary
> commands.

I wouldn't trust the script to protect its permissions. I'll suggest
two better solutions:

1) Create a new user and a new group, put the new user in that group.
Create a program only executable by a member of that group that is
setuid to your user. Make that program sanitize the context and then
run your script.

2) Write a wrapper program to execute your script after sanitizing the
environment and parameters. Have the ssh key launch that wrapper
program rather than your script directly.

A a general rule, scripts for general-purpose shells do a lousy job of
protecting from privilege elevation attacks.

DS
From: Simon Tatham on 3 Feb 2010 18:38
David Schwartz <davids(a)webmaster.com> wrote:
> 2) Write a wrapper program to execute your script after sanitizing the
> environment and parameters. Have the ssh key launch that wrapper
> program rather than your script directly.

Even better, do this bit via userv:

http://www.chiark.greenend.org.uk/~ian/userv/

which works by having the directly invoked client program open a
Unix socket connection to a server which launches the real service
script. So there's no risk of accidentally incomplete sanitisation,
because here the environment and parameters are sanitised _by
default_: anything you do want to pass in has to be passed in
deliberately.
--
Simon Tatham What do we want? ROT13!
<anakin(a)pobox.com> When do we want it? ABJ!
From: Antoine EMERIT on 28 Feb 2010 15:52
On 03.02.2010 23:16, David Schwartz wrote:
> 2) Write a wrapper program to execute your script after sanitizing the
> environment and parameters. Have the ssh key launch that wrapper
> program rather than your script directly.

It sound like the use of SUDO thru a SSH connection.
 | 
Pages: 1
Prev: Fear about a WLAN card
Next: how to zero nfs counters