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