Hope this didn't get sent twice, I think my first send failed.

Ok guys, to simplify things I'm replying to the past few messagesd from Mario, Nikodemus and Erik here:

First about the sandboxing, chroot issue:

Let me start by saying, that I've set up one of my LAN servers to test my approach to sandboxing. Like I have been saying, in the Apache config file doing something like the following will only allow Apache to run clhp code in the clhp directory. As long as the AddHandler directive is only inside /project/clhp it restricts Apache to only using the clhp module in that directory. If anyone else tries to access a .clhp page (outside of /project/clhp they'll just get the contents of the file output as plain text.

<Location /project/clhp> AddHandler clhp-handler .clhp DirectoryIndex index.clhp index.shtml index.html index.htm </Location>

So if you restrict it to me as far as sandboxing goes, I think it's slightly paranoid, and quite a bit more work, it would probably mean running a separate Apache on another port chrooted.

You currently have apache running as User www-data, who does have write permissions to /var/www and everything below it, Now you can change Apache to run as nobody, and that will not be an issue. I've also just tested this on my Debian box.

I think Apache's configuration combined with *nix file permissions, and Debian's already tight security configuration will be enough.

Mario> The problem is not necessarily one of us doing malicious things Mario> intentionally (I guess that goes without saying :-) ) but Mario> unintentionally by screwing up (c.f. Murphy's Law). So yes, it Mario> has to be sandboxed.

I agree with you here, all I can say to that is that all the code I plan on putting on will be written and tested locally before I consider putting it on the c-l.net server.

The biggest risk I've run across is having something like an endless loop and I'm just testing it now and looking at /apache-status

(loop for i = 1 then (1+ i) collect i until nil)

This doesn't hang apache.

As far as Murphy's law, I always keep that in mind, and I never want to say with complete confidence that something is secure or bug-free etc. But by developing on a local server before publishing on c-l.net (or anywhere else) hopefully those bugs will be found before they can get exploited publicly.

Nikodemus> Very true. And unrestricted CGI is a Bad Idea on a Nikodemus> production server with multiple projects. All it takes is Nikodemus> one project with one mistake in one CGI script, and Nikodemus> Common-lisp.net grinds to halt because the disk gets Nikodemus> written full, or all the time is spent swapping, or an Nikodemus> attacker uses the CGI to snoop the system, etc. Nikodemus> Nikodemus> On a single project website this is not that much of a Nikodemus> problem: people can hurt themselves, but not others. Nikodemus> Nikodemus> Like Mario pointed out, this is why chrooting is Nikodemus> *vital*. It's not about trust, but about security and Nikodemus> robustness. And I'd add "running as nobody" and "cmhod -R Nikodemus> o-w" to the list. ;) ... Nikodemus> Very true. But then I don't think we should be offering PHP Nikodemus> either, ;)

Which can happen just as easily with something like PHP or shtml it's more a question of having the system set up properly. If you want to have that view, then you should take away shell access and disable cron jobs for all users as well. By no means do I think you should actually do that.

There has to be a level of trust, the only people who would be able to exploit anything already have ssh access. and personally if I was looking to bring down the server I could do it much easier with a short line perl script run from the shell than to do it via Apache.

Erik> If he wants to put his neck on the line then I think we should Erik> let him. :-) If clhp is too much of a strain on the server I'll Erik> take it down and perhaps months down the line when he's come up Erik> with a better way I'll let him try it out again. We're here to Erik> help CL developers and I think we should try our best to do Erik> exactly that. Now, you're right that we shouldn't bend-over Erik> backwards for everyone and their needs but this one seems fairly Erik> harmless.

I'll put my neck on the line as far as setting it up so it only works inside /project/clhp, once it's tested and has proven itself you guys can consider it for more of the site. I'd encourage you all to try it for yourselves at home and test it. Because I think it would be useful to add some features to the clo site. Since it's CMUCL based many of the issues you are considering like being able to integrate SQL into the main site may be quite trivial using CLHP.

The best way I could convince you is to have you guys use it. But even if you decide that you want to use it for yourselves, I stress that all the code should be tested on your own personal machines before placing it on the "real" server.

Erik> If the server halts because of a full disk or CPU grinding then Erik> that's what happens and I'll be very reluctant to try out clhp Erik> again. Anthony feels pretty secure that this won't happen so Erik> I'm willing to chance it.

I'm willing to take that chance. Like I said, the stuff I want it for is tested before it would go public.

Erik> Anthony, what they are pointing out are likely to be Erik> requirements in a production scenario, anyway. Is there a way Erik> to make sure that clhp pages do not have access to files outside Erik> it's directory structure?

No CLHP can have read access. But if Apache is configured to run as nobody, it won't have write access to anything but /tmp and /var/tmp (which I don't plan on using at this point). The only other directories I could give write access to would be under my the directories I own.

Like I said above having read access is no more of a problem than allowing users to have a shell account. You take a risk, but you have to make sure you set the proper file security.

Ok there's one more answer to one of Nikodemus' questions:

Nikodemus> I'm probably missing something obvious here... but why? Nikodemus> What kind of dynamic content do you need? Nikodemus> Nikodemus> Or do you mean vital in the sense of "prove it works"?

Mostly it's to prove it works, However I do have one page written which allows you to view the actual page source of pages in /project/clhp, so that would be dynamic content.

Now that page works by passing the filename to the page in a GET request, so to view the source of http://common-lisp.net/project/clhp/index.clhp the URI is: http://common-lisp.net/project/clhp/view-source.clhp?page=/index.clhp

Now you may be worried that this will allow anyone to read any file on the serve that apache has read permission for, by passing a query like ?page=/../../../../etc/passwd, but I've written it so if it sees "../" anywhere in the query it replaces it with a default value. (if (search "../" page) "/index.clhp" page)

So basically the only reason I need it is to show examples of how it works.

Whew,

Anthony

-- (incf *yankees-world-series-losses*)