Various platforms

[J.P. King]

> But isn't one of your goals security?  You can build an ssh that works
> on 9.X if needed, but I'd recommend shipping a more modern build as
> well.
One of my goals is _improved_ security, however only of the
communication with our machines by people connecting from the
outside world.  Whilst I would like security in the world to
be improved, it is hard for me to do this from the outside
(projeects like OpenSSH not-withstanding).

Unless there is some security hole introduced into OpenSSH
by building it on an older platform, then I don't see how
I have lost.  In the meantime  I have gained because the
people connecting from an old HP-UX box, and those connecting
from a more modern one can all use a secure channel to talk
to their machines back in Cambridge.

If I have failed to take account of something then I would
like to know, but based on the last year this program has 
had not trivial amounts of success in reducing passwords
being sniffed by Cambridge 'scholars' visiting other
institutions.

> : I am compiling on the oldest variants of platforms I can, and testing
> : on more recent versions to make sure that they still work.  I am
> : compiling them statically, at least where the OS doesn't fight me
> : hard enough to prevent this.
> 
> 9.03 libc is ancient and I wouldn't want to use it in a security
> application.

I certainly don't claim to be a security expert, so I am prepared
to admit that I may have forgotten something, but I cannot think
of a way to use an 'insecure' statically compiled libc on a 
non priveledged binary on a CDrom to even allow a hacker to
intercept data being sent by a user to one of our machines?
The only way I can see this possible requires the attacker
to have root priveledges already, and circumventing the binary
is much easier than compromising it.

One thing I should perhaps make clear, which may not have
been obvious, the only applications being shipped on the
CDrom are ssh and scp - sshd is NOT shipped, and if you
thought that was the case then I can see your concerns.  This
is not meant to be a means of distributing precompiled sshd
binaries, just the clients.

> : Sounds good, I will try to use that if I need to recompile.  I am somewhat
> : wary about pulling in more things than I need, in case one of the other
> : things upsets the applecart so to speak.
> : 
> : I was hoping that OpenSSH could be made aware of these aspects in some
> : fashion, such that when I compile a future version this problem doesn't
> : arise.
> 
> setresuid() is an HP-only thing and I don't really want to add detection
> for it.

FreeBSD supports it too I have not checked anywhere else.  I was more
thinking of detecting the lack of setreuid as well as the lack of
seteuid.  I am not sure what not detecting it gains you, especially
since the wrapper replacement for seteuid is so simple?  However
if you don't then I will keep working around it, it just seems
strange to me.  *shrug*


Julian

P.S.  It occurs to me that as I am about to send this the set[r]e[s]uid()
call will only be used by the sshd, won't it - I guess I could have
got around it by doing make ssh - I just don't like not compiling
the whole suite, because that involves checking the Makefile out
ludicrously carefully to confirm that it is written with a valid
dependancy list.