Stephen Frost wrote:
* Trevor Talbot ([EMAIL PROTECTED]) wrote:
There are various platform-specific security features that might be
useful, like reserved port ranges and file permissions, but they are
so specific to the scenario they're designed for that it's hard to
create a generic solution that works well by default -- especially if
you want to run without requiring administrative privileges in the
first place.
Agreed. A guarentee that the process listening on a particular port is
what you're expecting isn't something that upstream can give. It needs
to be done through some situation-specific mechanism. There are a
number of options here, of course: SSL, Kerberos, SELinux, even things
like the tiger IDS. Reserved ports really aren't all that great a
solution in the end anyway, to be honest.
UNIX socket kernel credential passing was mentioned in an earlier post,
but I didn't see it raised again. All of the above mechanisms still
require a piece of information to validate "trust". SSL requires a copy
of the public certificate. UNIX socket credential passing would be much
cheaper to validate - all it requires is the userid or username.
I prefer UNIX sockets with kernel credential passing over TCP/IP with
username/password or the more expensive SSL. I do not like storing
passwords or private certificates in a place available to the web user,
as other web users would then also have access. I do not have evidence,
but I am under the impression that the TCP/IP stack incurs additional
overhead on connect(), send(), recv(), and close() than UNIX sockets.
Yes, Java doesn't work with UNIX sockets - but both Perl and PHP do. The
only reason Java doesn't is because Java itself doesn't support UNIX
sockets, and the Java JDBC provider is pure-Java.
How expensive would it be to implement a "server_user" db open parameter
that would perform reverse credential passing to validate? "dbname=XXX
port=5432 server_user=postgres". If the server can't prove it is
postgres through UNIX socket credential passing, it fails. Similarly,
identd may be usable in reverse? I've seen many people claim identd is
insecure - but it is secure if I am the one running it, is it not?
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
