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

List:       zope-coders
Subject:    [Zope-Coders] [patch] z2.py on UNIX: security fixes + security enhancements
From:       Behrens Matt - Grand Rapids <Matt.Behrens () Kohler ! Com>
Date:       2001-10-26 13:07:35
[Download RAW message or body]


The attached patch addresses the following issues in z2.py.  All these 
issues are related to ZServer being started as root on UNIX systems.  It 
does constitute something of a change to the startup process, but I've 
tried to make it be as non-intrusive as possible while still making sure 
the end-user is aware of what's going on.


Issue 1, the big one:  Z2.pid is written by the less-privileged user. 
This means Z2.pid can be changed by that less-privileged user, and root 
can be tricked into killing an arbitrary process by running "stop".

The first part of addressing this is moving the writing of Z2.pid up 
before the setuid call.  However, var needs to be writable by the 
less-privileged user in order for Zope to operate.  var being writable 
like this means that the less-privileged user can delete and re-create 
Z2.pid, and still trick root as above.  I solved this by forcing var to 
have the sticky bit set if ZServer is started as root.  Other solutions 
involved having to modify the start and/or stop scripts, which I didn't 
think would be cool for upgraders.


Issue 2:  'nobody' is not a good user to drop to, simply because other 
system daemons on some UNIXen as well as many third-party packages 
depend on it to have no permissions whatsoever.  The less-privileged 
user needs to have Data.fs read/write rights, so if any of these other 
daemons is compromised, Data.fs could be read.

The way this needs to be addressed is by encouraging the end-user to 
create a dedicated user to run Zope as.  To that end, I've removed 
'nobody' as the default and forced -u to be specified on the z2.py 
command line if you're starting as root.  -u nobody can still be 
specified, but it will issue a warning on startup.  Also, if z2.py is 
actually started as nobody, the same warning will be issued.


Issue 3:  The default UNIX umask, 022, means that any new files created 
in var will be created with read permissions for everyone on the system. 
  New files are created when the database is packed, as well as when 
gadfly is used.

If the umask is not set to 077, a warning is issued on startup.  There 
is probably legitimate reason to run with other umasks, so I didn't 
think it was proper to force ZServer to be run with my particular choice.


This patch also spits out INFO when it actually does the setuid.


This patch is against 2.4.1, although it cleanly applies to 2.4.2.  I'm 
sitting on the 2.4.2 update for OpenBSD (I'm maintaining that port) 
until there's a resolution of some kind that I can include with it.

-- 
Matt Behrens <matt.behrens@kohler.com>
System Analyst, Baker Furniture



["z2_py.diff.gz" (application/octet-stream)]

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