client-server issue

Hi,
I have a server which serves requests from clients and handles harware
access through several interfaces (RS232, EPP, usb, etc.).
The server resolves conflicts for multiple access to the hardware and
provides some filtering capabilities in order to prevent unwanted
clients to mess up with the hardware.

To control the server and its behavior I have a specific client which is
able to send commands to the server.
Since this server-controller client can be run in several instances on a
fairly broad network, I would like to allow only one instance of the
client to be able to change settings on the servers, while the others
can only monitor its behavior.

What I came up with is this (and it may sound pretty naive):

1. C (client) logs in S (server) and receives a T (token). The token has
a fixed lifetime (say 5 seconds).
2. once a T has been generated, no other logins will be accepted.
3. C will use T whenever needs to change settings on S.
4. C will periodically ask for T extension.

In this way once C has access granted all the other instances of C will
not be able to change settings on S. Once C is closed (or crashed) T
will expire in S and a new T can be granted to another instance of C.
If S will crash (should never happen! but it will), a new login will be
required.

I understand this is a home-brewed solution and may have serious flaws,
but I hope some of you can suggest a better approach.
Thanks a lot,

Al

--
Alessandro Basili
CERN, PH/UGC
Electronic Engineer

On Fri, 18 Mar 2011 22:52:00 -0400, Alessandro Basili <(E-Mail Removed)> wrote:

> fairly broad network, I would like to allow only one instance of the
> client to be able to change settings on the servers, while the others
> can only monitor its behavior.

Have the client gpg sign the commands, and the have the server only
accept the command if the signature is valid.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On 3/18/2011 10:29 PM, David W. Hodgins wrote:
> On Fri, 18 Mar 2011 22:52:00 -0400, Alessandro Basili
> <(E-Mail Removed)> wrote:
>
>> fairly broad network, I would like to allow only one instance of the
>> client to be able to change settings on the servers, while the others
>> can only monitor its behavior.
>
> Have the client gpg sign the commands, and the have the server only
> accept the command if the signature is valid.

How should I provide a gpg to a single client? where does it get it
from? The client here is an instance of a program, is like having
several instances of thundirbird sending emails always from the same
recipient, how can I allow only one instance of TB sending emails?

Maybe I am missing your point.

>
> Regards, Dave Hodgins
>

Alessandro Basili wrote:
> On 3/18/2011 10:29 PM, David W. Hodgins wrote:
>> On Fri, 18 Mar 2011 22:52:00 -0400, Alessandro Basili
>> <(E-Mail Removed)> wrote:
>>
>>> fairly broad network, I would like to allow only one instance of the
>>> client to be able to change settings on the servers, while the others
>>> can only monitor its behavior.
>>
>> Have the client gpg sign the commands, and the have the server only
>> accept the command if the signature is valid.
>
> How should I provide a gpg to a single client? where does it get it
> from? The client here is an instance of a program, is like having
> several instances of thundirbird sending emails always from the same
> recipient, how can I allow only one instance of TB sending emails?
>
> Maybe I am missing your point.
>
With gpg you can allow one particular (pre-determined) client to
control. Reading the original post, what you are aiming for is something
like controlling PTZ on a webcam - anybody is allowed to change it, but
only one person at a time. The proposed scheme will work, it's similar
to what things such as DHCP do. However I would try to keep all the
intelligence in the server - if it is possible for the server to
identify a client (e.g. client IP address/port, if you are using
persistent TCP connections between client and server), you can set a few
global variables in the server indicating which IP/port has control, and
when last it issued a command. If a command comes in from another
IP/port, and 'last issued command' is more than 5 seconds ago, replace
the 'current control' by the new IP/port.

-j

On Sat, 19 Mar 2011 16:56:25 +0200, jack <(E-Mail Removed)> wrote:

>Alessandro Basili wrote:
>> On 3/18/2011 10:29 PM, David W. Hodgins wrote:
>>> On Fri, 18 Mar 2011 22:52:00 -0400, Alessandro Basili
>>> <(E-Mail Removed)> wrote:
>>>
>>>> fairly broad network, I would like to allow only one instance of the
>>>> client to be able to change settings on the servers, while the others
>>>> can only monitor its behavior.
>>>
>>> Have the client gpg sign the commands, and the have the server only
>>> accept the command if the signature is valid.
>>
>> How should I provide a gpg to a single client? where does it get it
>> from? The client here is an instance of a program, is like having
>> several instances of thundirbird sending emails always from the same
>> recipient, how can I allow only one instance of TB sending emails?
>>
>> Maybe I am missing your point.
>>
>With gpg you can allow one particular (pre-determined) client to
>control. Reading the original post, what you are aiming for is something
>like controlling PTZ on a webcam - anybody is allowed to change it, but
>only one person at a time. The proposed scheme will work, it's similar
>to what things such as DHCP do. However I would try to keep all the
>intelligence in the server - if it is possible for the server to
>identify a client (e.g. client IP address/port, if you are using
>persistent TCP connections between client and server), you can set a few
>global variables in the server indicating which IP/port has control, and
>when last it issued a command. If a command comes in from another
>IP/port, and 'last issued command' is more than 5 seconds ago, replace
>the 'current control' by the new IP/port.

Yes, but... The server may be handling multiple request for access in
parallel, so you really want to stream those access into a queue at the
server. Then another process drains the queued requests into actual
webcam (or whatever widget) controls. It is this server that knows about
the requests, can deduplicate queued requests (delay processing requests
by a few seconds, drop any requests that are already in the queue).

Key is to control access to the one resource, and that may be done with
queues and delays. Delays are important when accessing a physical
resource that you don't want to wear out.

OTOH, OP may be asking for session control, where only one client gets
control at a time -- this is where a global variable (as easy as touch
or rm filename in world-writable filespace for the writer, and a [ -f
filename ] ... for the new client) indicates if the resource is busy
and responds to the client accordingly.

Grant.

On 3/19/2011 7:04 PM, Grant wrote:
> OTOH, OP may be asking for session control, where only one client gets
> control at a time -- this is where a global variable (as easy as touch
> or rm filename in world-writable filespace for the writer, and a [ -f
> filename ] ... for the new client) indicates if the resource is busy
> and responds to the client accordingly.
>

Session control is maybe a better phrasing, since I want one session
active as long as the client is running, once the client "logs off" or
quits than another can log in and take control.

Didn't understand quite well what you meant with
> as easy as touch
> or rm filename in world-writable filespace for the writer, and a [ -f
> filename ] ... for the new client

On 3/19/2011 9:56 AM, jack wrote:
> With gpg you can allow one particular (pre-determined) client to
> control. Reading the original post, what you are aiming for is something
> like controlling PTZ on a webcam - anybody is allowed to change it, but
> only one person at a time. The proposed scheme will work, it's similar
> to what things such as DHCP do. However I would try to keep all the
> intelligence in the server - if it is possible for the server to
> identify a client (e.g. client IP address/port, if you are using
> persistent TCP connections between client and server), you can set a few
> global variables in the server indicating which IP/port has control, and
> when last it issued a command. If a command comes in from another
> IP/port, and 'last issued command' is more than 5 seconds ago, replace
> the 'current control' by the new IP/port.
>
> -j

That is pretty much what I proposed in the very beginning, only
difference is that the "token" is not sent to the client but will expire
in the server.
Unfortunately client IP address/port is not enough information, since
multiple clients may run from the same IP address/port (actually the
port is fixed), so I would need the pid as well.
Since all this information is clear in the protocol, someone can fake
all this information and gain access regardless of all these efforts.

After some readings I now tend to believe the proposed pgp solution it's
the safest, even though I still didn't understand how I should implement
it. Need further reading... but I'm catching up ;-)

Alessandro Basili wrote:
> On 3/19/2011 9:56 AM, jack wrote:
>> With gpg you can allow one particular (pre-determined) client to
>> control. Reading the original post, what you are aiming for is something
>> like controlling PTZ on a webcam - anybody is allowed to change it, but
>> only one person at a time. The proposed scheme will work, it's similar
>> to what things such as DHCP do. However I would try to keep all the
>> intelligence in the server - if it is possible for the server to
>> identify a client (e.g. client IP address/port, if you are using
>> persistent TCP connections between client and server), you can set a few
>> global variables in the server indicating which IP/port has control, and
>> when last it issued a command. If a command comes in from another
>> IP/port, and 'last issued command' is more than 5 seconds ago, replace
>> the 'current control' by the new IP/port.
>>
>> -j
>
> That is pretty much what I proposed in the very beginning, only
> difference is that the "token" is not sent to the client but will expire
> in the server.
> Unfortunately client IP address/port is not enough information, since
> multiple clients may run from the same IP address/port (actually the
> port is fixed), so I would need the pid as well.

For TCP/IP the set (src-IP, src-port, destination-IP, destination-port)
fully identifies a connection - the most common case with multiple
clients from the same IP is where scr-IP, destination-IP and
destination-port are fixed, and src-port varies. So unless you are using
things like Unix domain sockets or named pipes to connect to the server
it should suffice.

> Since all this information is clear in the protocol, someone can fake
> all this information and gain access regardless of all these efforts.
>
> After some readings I now tend to believe the proposed pgp solution it's
> the safest, even though I still didn't understand how I should implement
> it. Need further reading... but I'm catching up ;-)

If you are concerned about another client snooping on the protocol and
'stealing' the currently active token, you'll end up using some form of
crypto. Either implement the token scheme as you suggested but wrap the
entire communication in SSL using some ssl libraries, or use some form
of challenge/response scheme for the tokens, be it pgp or something
else. The key is to never send the actual token over the link, but to
send a random nonce to the client, and have the client reply with a hash
of that nonce using something that only /that/ client can know.
Things pretty quickly get complicated there though, e.g. defending
against replay attacks etc.

-j