From: John Tobey <[EMAIL PROTECTED]>
Date: Sun, 2 Mar 2003 10:42:29 -0500
On Sun, Mar 02, 2003 at 10:19:17AM -0500, Joel Gwynn wrote:
> I'm more concerned about other pair users being able to access the file.
> Currently, the file is stored above the document root, but it has to be
> readable by the cgi script, hence the user nobody in group www.
Without help from a system administrator, the solution space is pretty
thin. Obviously, when the server runs all CGIs as the same user and
group, this effectively deprives CGIs of the standard Unix security
features, at least with respect to other, untrusted CGIs on the same
system.
Amen. I think this is the root (pun intended) of the real problem.
The clean and safe solution would be to run your own copy of the web
server (if allowed) or configure the existing server for "suExec" (if
supported).
Hmm. I don't see how a running server process would change EUID from
the unpriviledged "nobody" user without having a password stored
somewhere, readable either to user "nobody" or group "www". In which
case you are giving away more than just database access to anyone who
shares the server.
But then, I am not familiar with this server feature. Maybe the
password is kept in a config file which is read as root before dropping
privs?
Barring those, the only solution I can think of is to write a setuid
program owned by you that runs the "real" CGI script. However, you
should be aware of the long history of security bugs affecting setuid
programs written by competent programmers and the potential hole that
this would open up to your account. See `perldoc perlsec` and
especially the section "Security Bugs". (Note that suidperl may not
be installed, as it has had some of the aforementioned bugs.)
A minimal solution would be to write a setuid "helper" program (not a
script) that just changes EUID, copies to stdout a specially-protected
password file (the name of which is built into the binary), and exits.
The CGI script itself can then run under normal privilege (which is much
safer), executing this program when it needs the DB credentials. But
there's a catch: You would still need to figure out a way to ensure
that only *you* can run the helper program. I'd bet that if you have to
start from a shared user ID, there's simply no way to do this. You
would have to present credentials of some sort to the helper program in
order to tell it to give you your DB credentials, but you'd still
couldn't keep your helper credentials secret from other shared users.
Even this solution will not work if, for example, the filesystem is
configured to ignore the setuid bit.
It is a question for the system administrator.
And the sysadmin might not be willing to create a unique UID for you in
the first place, in which case (I believe) no solution is possible, and
you are back to square one. Again.
----
Let me digress a bit in order to present my current server/database
security solution. It doesn't help with Joel's original problem, since
it requires separate UIDs for separate servers, but it does eliminate
the unbounded regress of having to present credentials in order to get
access to more credentials. Furthermore, I've never seen it discussed
anywhere, so I'd be interested in hearing everybody's comments.
In a nutshell, I use the PostgreSQL "ident" authentication feature,
and restrict access to the DB server to connections coming from the
loopback address. This has the distinct advantage of making a password
unnecessary: Since the DB server can securely and reliably query the
name of the user who makes the incoming connection, each user must first
prove who they are to the OS's satisfaction, and then the DB server can
confidently grant access to that DB user account, and no other.
(Naturally, this also requires proper packet filtering to eliminate
spoofed loopback packets coming from the network. I haven't tried to
work out whether a local exploit is possible, but I suspect it would be
practical only to the extent that TCP sequence numbers are predictable.)
Unfortunately, since multiple servers require multiple UIDs, it is
necessary to run separate server instances under VHR. (Or maybe use
"suExec" -- like I say, I am not familiar with this feature.) The extra
resource requirements and admin overhead probably explain why people try
to get away with a single UID.
This works for local database access, which is all I need, but is
insecure to use over a network from any host where you don't control the
ident server. The simplest way to adapt this scheme for secure remote
access, it seems to me, would be to use SSH to connect to the DB server,
and let SSH handle authentication and forward an encrypted DB
connection. Of course, this should also be done without passwords by
using SSH public key authentication, but since the private key must be
on the CGI server, and anyone with access to the private key gets a free
ride into the RDBMS host system, the CGI server still needs to be set up
locally with separate accounts for each separate database user.
-- Bob Rogers
http://rgrjr.dyndns.org/
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
