[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: New protocol proposal fishs://
From:       Jörg Walter <jwalt-kde () garni ! ch>
Date:       2003-03-25 11:31:25
[Download RAW message or body]

On Tuesday, 25. March 2003 00:11, Willy De la Court wrote:
> On Monday 24 March 2003 23:21, Jörg Walter wrote:
> <SNIP>
>
> > > From a security standpoint, it would be preferable if there was just
> > > one fishsrv.pl file for the system, that way a person couldn't change
> > > the fishsrv.pl to give themselves additional capabilities.
> >
> > Which is nonsense, since we now have an 'EXEC' command. Moreover, we rely
> > on the fact that the shell is accessible. fish:// has never been a
> > protocol designed for security against ill-behaved clients - this is
> > impossible by (protocol) definition. Protection against ill-behaved
> > servers is a different matter, but is either implemented (fish must be
> > robust against rubbish sent, as it may occur during general usage due to
> > newly found incompatibilities), or impossible (How can a client check the
> > checksum of a compromised server script?
>
> I have some ideas on that it's based on challange response authentication
>
> some peudo code
>
> checksumoffishsrv = calucalted at compile time
> seed = randomstring();
> checksum = md5(seed + checksumoffishsrv)
> send command CHECKSUM(seed) to the fishsrv
>
> ------ server executes -----
> server receives command CHECKSUM(seed)
> srvchecksum = md5(.fishsrv.pl)
> mychecksum = md5(seed + srvchecksum)
> send mychecksum back to slave
> ------ slave again-------
> slave compares checksum with mychecksum received from .fishsrv if they
> match .fishsrv is ok
>
> this should make it very hard to tamper with

No, not at all. The client script just needs to save the 'correct' checksum 
and fake that. And if you make up trickier schemes, a tweaked script could
save the original one and call that for the verification.
It is impossible, not just "practically impossible", but even provable 
impossible to authenticate software on an untrusted remote machine. I believe 
not even the infamous TCPA could change that (though it makes it very hard).
This is the same problem as with any other server software: you cannot protect 
gainst or even detect malicious modifications.

Face it: remote shell access is remote shell access is remote shell access. 
The client is resonably resistant against remote tamperings, but that's it. 
The server side is wide open, and nothing can change that.

> > Solve the halting problem first, please ;-).
>
> Halting problem????

The prime example for unsolvable problems.

> > fish://root%foo@example.com - connect foo@example.com, su to root.
> > fish://bar=internal.example.com%foo@example.com
> >    - connect foo@example.com, connect from there to
> > bar@internal.example.com
> > fish://root%bar=internal.example.com%foo@example.com
> >    - connect foo@example.com, connect from there to
> > bar@internal.example.com, then on that machine su to root
> > and so on.
> >
> > This would be implemented with a new protocol command, PROXY for example.
> > By using a system-wide start_fish_server, PROXY allows the sysadmin to
> > choose sudo or su based on local circumstances, avoiding the whole "the
> > user must know that" issue. .fishsrv.pl could do some smart things to
> > autodetect sudo vs. su as well.
> > Shell mode would resort to 'su only', but shell mode is very rare anyhow
> > -
>
> It will be used now to replace the superuser filemanager (that was the
> initial idae behind it anyway)
>
> well in my program kcmdhcpd i use the shell mode to start/stop local
> daemons since i can use the same protocol to load/save a file wheter it's

No, shell mode is not your recent "su when localhost" modification. Shell mode 
is what gets used when there is no perl on the remote machine. (Another 
reason why any attempt to authenticate the remote side is pointless - remove 
perl, and foo).

So what I wanted to say is: If .fishsrv.pl is used on the server, we can play 
as many autodetect tricks as we like to. If not, the user must live with 'su 
only'. A good solution IMHO.

-- 
CU
  Joerg

PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E  7779 CDDC 41A4 4C48 6F94

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]