[lists] Re: [clo-devel] Getting clhp installed on Apache

[Anthony Ventimiglia]

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*)