[ZCM] [ZC] 1/ 7 Resolve "z2.py on UNIX fixes + security enhancements"

[Collector: Zope Bugs and Patches ...]

Issue #1 Update (Resolve) "z2.py on UNIX fixes + security enhancements"
 Status Resolved, Zope/bug+solution medium
To followup, visit:
  http://collector.zope.org/Zope/1

==============================================================
= Resolve - Entry #7 by zigg on Mar 14, 2002 12:20 pm

 Status: Accepted => Resolved

Committed to trunk.
________________________________________
= Comment - Entry #6 by zigg on Feb 25, 2002 9:16 pm

I am currently maintaining fixes for this as well as a missing initgroups() call at http://www.zope.org/Members/zigg/UnixSecurityPatch.  This should be preferred over the z2.py patch attached to this message.
________________________________________
= Assign - Entry #5 by matt on Nov 30, 2001 2:52 pm

 Status: Pending => Accepted

 Supporters added: matt

I dont promise to do anything RSN but I'll own this.
________________________________________
= Edit - Entry #4 by klm on Oct 30, 2001 1:13 am

Changes: Submitter id: 'Brian' => 'zigg', submitter name, submitter email
________________________________________
= Edit - Entry #3 by klm on Oct 29, 2001 4:18 pm

Changes: submitter email
________________________________________
= Edit - Entry #2 by klm on Oct 29, 2001 4:16 pm

Changes: submitter name, submitter email
________________________________________
= Request - Entry #1 by Brian on Oct 29, 2001 1:44 pm

Uploaded:  "z2_py.diff.gz"
 - http://collector.zope.org/Zope/1/z2_py.diff.gz/view
(Submitted by Brian on behalf of Matt Behrens)

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
==============================================================