Re: Install doesn't start properly
Please keep the mailing lists in the loop. I do not control the Zope source, and others may have an opinion as well. I am CC-ing Zope-Dev on this as this discussion is more appropriate there. On Mon, Oct 22, 2001 at 01:12:33PM -0400, Behrens Matt - Grand Rapids wrote:
The above URL confuses running as nobody and having the files owned by nobody.
It is not terribly clear, and it reflects a shallower understanding of the problem that I used to have. So I dragged out a bindist, untarred it as root, and performed a few experiments, see below.
Files should be owned by root (which it would do if installed as root) and you can run as nobody, provided that nobody has permission to write to the var directory.
First, actually, untarring as root sets the ownership of a lot of the stuff in my solaris bindist to 506:100 (brian:users, it says in the listing.)
Default behaviour when using tar as root; it'll preserve the UID and GID of the person that created the tar.
When I first went on my "nobody" crusade I was under the assumption that "nobody" needed to be able to rw Data.fs as well. That should probably be clarified when advice is given to make "var" nobody-writable. I'm guessing there are more than a few people who take "make var nobody-writable" as requiring that files inside it also are nobody-writable. Maybe this is not anyone's responsibility but I don't want to give someone who doesn't know any better incomplete advice.
In any event, the drop-to-nobody setup is still not perfect, though. Here are a few examples I just tested now:
1. "nobody" can change Z2.pid since it owns it; this can be used to trick root into killing an arbitrary process. Solution: Z2.pid should be written before the setuid call.
Agreed.
2. "nobody" can arbitrarily destroy and replace any file in var, still leaving the possibility open for mischief. Writable directories mean you can rename, remove, etc. Solution: The sticky bit could get around this.
I don't see how? What is the point of having one writeble directory for the process and then make it unwritable? The point of the var directory is to have only one place where the server process can do all its writing (which it needs to be able to do in order to operate). Note that if you feel uncomfortable with the user 'nobody', you can also dictate that Zope switches to another UID. On Debian www-data is used, for example.
3. Packing doesn't work unless "nobody" can read Data.fs. Letting "nobody" read Data.fs nullifies most of the security we gained. If we do let "nobody" read Data.fs, then when packing is performed we end up with a nobody-owned Data.fs.
Nobody will have to be able to read Data.fs, otherwise the whole Zope process wouldn't work! Same for writing. The only way around this is having a separate server process control the writing (ZEO), or not run as root (and have another process like Apache provide port 80).
4. Anything else that uses var, such as gadfly, ends up nobody-owned. I don't see any programmatic way around this. Putting sensitive data in gadfly is downright silly IMO, but in a general-use platform, I don't control what people do. Default to secure, if the end-user overrides our security, it's their fault if something is compromised.
I think we make it pretty clear that Gadfly is for demo purposes only, and it isn't useful for any critical data for many more reasons.
Not really "nobody"-related but still of note: with the default UNIX umask, new files (i.e. packed Data.fs) are created with read permissions for group and other. I don't see a recommendation to set umask 077 anywhere but I may just be missing it.
I don't think there will be any problems with this.
I know I'm being a pain in the arse, but this stuff is pretty important, I think. I'd like to get it fixed up, and I'm happy to help with code or doc changes or whatever, as well as keeping the specifics under wraps until a fix is committed. In the meantime I think it's still best and will keep recommending that people run their installs as dedicated users.
The best way of having things changed you care about, is to submit patches and bug reports, especially if they are this detailed. Unfortunately, the bug collector is down right now (Ken Manheimer is working very hard on a replacement), but any suggestions are certainly still welcome, preferably to the mailinglists. -- Martijn Pieters | Software Engineer mailto:mj@zope.com | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
Martijn Pieters wrote:
Please keep the mailing lists in the loop. I do not control the Zope source, and others may have an opinion as well. I am CC-ing Zope-Dev on this as this discussion is more appropriate there.
Okay, as I said, I just didn't care to give the specifics wide publicity if it was going to be problematic for anyone having to rush to get fixes out in the face of details. Incidentally, as far as snipped portions go, it can be safely assumed I'm in agreement with you.
On Mon, Oct 22, 2001 at 01:12:33PM -0400, Behrens Matt - Grand Rapids wrote:
Files should be owned by root (which it would do if installed as root) and you can run as nobody, provided that nobody has permission to write to the var directory.
First, actually, untarring as root sets the ownership of a lot of the stuff in my solaris bindist to 506:100 (brian:users, it says in the listing.)
Default behaviour when using tar as root; it'll preserve the UID and GID of the person that created the tar.
Yes, it was just a point from the point-of-view of someone who may not know better. Perhaps "install" should recursively change ownership?
2. "nobody" can arbitrarily destroy and replace any file in var, still leaving the possibility open for mischief. Writable directories mean you can rename, remove, etc. Solution: The sticky bit could get around this.
I don't see how? What is the point of having one writeble directory for the process and then make it unwritable? The point of the var directory is to have only one place where the server process can do all its writing (which it needs to be able to do in order to operate).
The sticky bit doesn't make the directory unwritable, it merely says that new files may be created, but old ones that you don't own may not be destroyed.
Note that if you feel uncomfortable with the user 'nobody', you can also dictate that Zope switches to another UID. On Debian www-data is used, for example.
I maintain the OpenBSD package (which I think will ship with 3.0, hurrah!), and I've solved this by stuffing the distribution into a root-controlled directory, then telling users the way to get Zope up and running is to create a dedicated user, then use a python script I added to the package (zope-instance) which populates an INSTANCE_HOME, creating start/stop scripts, Zope.cgi, inituser, and the like. Of course, back then, the whole port 80 thing was unknown to me. I was operating under the assumption that you front with Apache if you need to bind to 80. Incomplete research on my part.
3. Packing doesn't work unless "nobody" can read Data.fs. Letting "nobody" read Data.fs nullifies most of the security we gained. If we do let "nobody" read Data.fs, then when packing is performed we end up with a nobody-owned Data.fs.
Nobody will have to be able to read Data.fs, otherwise the whole Zope process wouldn't work! Same for writing. The only way around this is having a separate server process control the writing (ZEO), or not run as root (and have another process like Apache provide port 80).
Then we are back to the issue of having nobody be able to read Data.fs, ergo sensitive information in the ZODB compromised in case of a 'nobody' compromise. 'nobody' is counted on by all kinds of UNIX daemons to not have any sensitive permission, read _or_ write, in case of compromise. And actually, it looks like Data.fs is read in *before* the nobody drop. I had Data.fs root-owned with mode 600 (r/w only by owner) and Zope started fine. It was packing that was a problem.
Not really "nobody"-related but still of note: with the default UNIX umask, new files (i.e. packed Data.fs) are created with read permissions for group and other. I don't see a recommendation to set umask 077 anywhere but I may just be missing it.
I don't think there will be any problems with this.
No problems with not setting it, or no problems with telling people to set it? If it's the former, having umask 022 means I can waltz on in as any user on the system and read any newly-created file in var, including Data.fs after it's packed the first time. pack doesn't worry about file modes. I suppose I should join zope-dev now :-) -- Matt Behrens <matt.behrens@kohler.com> System Analyst, Baker Furniture
On Mon, 22 Oct 2001, Martijn Pieters wrote:
First, actually, untarring as root sets the ownership of a lot of the stuff in my solaris bindist to 506:100 (brian:users, it says in the listing.)
Default behaviour when using tar as root; it'll preserve the UID and GID of the person that created the tar.
Just FYI, this works "right" (IMO) under FreeBSD: files untarred as root are owned by root unless you use the p flag. Of course, this note only applies if you are just handling this item via doc changes; if you have install do the chown, it's moot. --RDM
R. David Murray wrote:
On Mon, 22 Oct 2001, Martijn Pieters wrote:
First, actually, untarring as root sets the ownership of a lot of the stuff in my solaris bindist to 506:100 (brian:users, it says in the listing.)
Default behaviour when using tar as root; it'll preserve the UID and GID of the person that created the tar.
Just FYI, this works "right" (IMO) under FreeBSD: files untarred as root are owned by root unless you use the p flag. Of course, this note only applies if you are just handling this item via doc changes; if you have install do the chown, it's moot.
I'm still wrestling with myself over whether or not this is an issue that needs to be addressed by the install script. On one hand, it really is the administrator's responsibility to check ownership and permissions. On the other hand, just about every other mature open source package out there installs and operates somewhere *other* than its source tree, setting permissions and ownerships as it goes. :-/ I will probably add it to the massive patch I'm working on and see what kind of reception it gets... (ObMozillaBug: while I was typing the first paragraph, a display bug showed me that I was, in fact, wrestling with "my elf".) -- Matt Behrens <matt.behrens@kohler.com> System Analyst, Baker Furniture
participants (3)
-
Behrens Matt - Grand Rapids -
Martijn Pieters -
R. David Murray