cancel
Showing results for 
Search instead for 
Did you mean: 

CGI server fixes

N/A

CGI server fixes

#1 CGI server needs overhaul to allow chrooting of indivdual accounts (or some other way of making sure that users can't read each others files, because having all users in the same group is a blatent security flaw almost worthy of micro$oft)

On the whole, something like this is needed, because at the moment, the whole setup is ridiculously insecure. May not happen since I guess it'd need a ground-up restructuring of the whole system, but this is just my tuppernorth of dissent against the status quo.

#2 allow directory-index overriding in .htaccess (ie turning off directory listings without having to create a blank html page to hide the index. )

#3 enable ability to transparently forward normal webspace address to cgi server (gets rid of that damn cgi appendage on the url) or set up php on the normal webserver.

More as I think of 'em

Ashe :shock:
11 REPLIES
csogilvie
Grafter
Posts: 5,852
Registered: 04-04-2007

CGI server fixes

3 is already possible if you request it, you can host your whole site on the CGI server.
N/A

CGI server fixes

I know #1 has been asked before, but I can't quite remember what the outcome was.
Ianwild
Grafter
Posts: 3,835
Registered: 05-04-2007

CGI server fixes

The answer to #1 was that there is no way to do this while still allowing full Shell access to the box. I have stated before that I would welcome a debate about making the CGI server FTP only, at which point we could chroot people in easily.

As it stands, the webserver needs to be able to read everyone's files and there isn't a feasible way to do that without having everyone in the same group...

Ben O'Hara has alrready been tasked with a lot of CGI work. I'll check, but afaik this does include solving the issues with some of the htaccess functions.

Regards,

Ian
N/A

CGI server fixes

Quote
The answer to #1 was that there is no way to do this while still allowing full Shell access to the box. I have stated before that I would welcome a debate about making the CGI server FTP only, at which point we could chroot people in easily.

I don't know enough to understand the implications of this. I think I've only ever used telnet for shell access because the CGI server password kept expiring.

What kind of thing (in non-unix-expert terms please Shockedops: ) would I not be able to do without shell access?
N/A

CGI server fixes

You would be able to do pretty much all that you need with regards file setup with only FTP access.

Though, here is a list of some of the stuff off the top of my head, and worlarounds if possible.

Crontab - Unless they launch there own custom solution, there will be no way to continue this service.

Chmod - Can be done with any quality FTP client

Download and unpacking files (wget and tar) - Files can be unpacked localy and bulk uploaded.

Compile - Some C based CGI application will not be able to run. However, most people that are using these, have the knowledge to compile them prior to uploading them.

There is very little else that can be done otherwise.

A chroot jail with FTP is simple, and would 100% prevent people from leaving there home directory. Nocomplaints or problems there then.

To chroot jail a shell process, would require that all the applications a person would need are provided to them. The problem with this is that it would mean every user needs a copy of them in there home dir. In terms of dir space, not possible.

There is however one complaint I have over chroot of the FTP space. This does not and will not solve the problem of accessing other users files.

The webserver will still have access to these files, as such, it is still a means through which you access them.

These include CGI and PHP based file managers and the fact you can still use PHP file functions on them. There is little guesswork involved in locating the file name.

1: Visit target site and URI path to file

2: Pre-pend your own directory name on as if the file is in your DIR

3: Change the username

4: Make CGI requests for your script and changing the files1,2 or 3 part until you strike gold.

This method is available now, and chroot jails will nto cure this.

I can however look at some fot he other providers I am with and show some of the tricks they use, even while providing shell access.
N/A

CGI server fixes

Right, thanks for that.

I see the difficulty - pretty much any change in the CGI server setup is going to break something that some user is doing.

For my own requirements I can imagine crontab would be useful at some point. But other than that, the ability to run my own cgi perl and php scripts using system-provided executables would probably cover it. If the loss of the other functionality is the price for not having all and sundry able to view passwords etc coded into those scripts, I'd go for the secure option. But that's just me ...
N/A

CGI server fixes

You can SETUID a users CGI files, meaning that the webserver runs the script under the users own username. That will mean some form of security can be placed upon the file system.

However, it is PHP that is the worry.

PHP runs as the same username as the webserver, from which there is no way around this at this time.

For the webserve to be able to read a file UserA wants to display, read permissions need to be granted to the webserver.

Now comes along UserB with a plan to cause problems.Regardless of any security measures put in place, UserB's PHP script can read UserA's, because PHP inherits the read permissions granted by UserA.

There is no real way around this and having looked, I can quaite easily access sites of other customers on other shared server platforms.

You can hide the directory structure from shell access, however, knowing your own structure is a subtle clue to locating theres, even if it is obscure.

For those in the know, SourceForge have a very simalar problem.

The only real security measure that can be taken is to hire dedicated hosting and have perminant firewalls and monitoring in place. Not cheap, but without setuid, there is no way around it.
N/A

CGI server fixes

Quote

To chroot jail a shell process, would require that all the applications a person would need are provided to them. The problem with this is that it would mean every user needs a copy of them in there home dir. In terms of dir space, not possible.

i'm no expert but wouldn't it be possible to "link" (i think that's the right term) to the bin directories and other shared dirs like that
N/A

CGI server fixes

Yes it would be very possible to link (or symlink, further again, symbolic link. It is a shortcut on steroids).

There is however one problem with it.

A chroot jail is designed such that there is no way in hell that filesystem functions or commands can access below root.

When you chroot, you set a dir to chroot to and the name of the program to use as the shell. The root dir (/) changes to this jail.

The symlinks you created however, still points to a node outside of the jail. As file system functions have no access to that location it is unusable.

Here are two examples



In this image we ahve a very basic example file map. The yellow area is the target chroot jail, and the "bin" directory in the yellow area are links to the real versions.



This is after perfoming the chroot (by the way, chroot would have failed, but this is only an example).

As I said, the root (/) changes to the target jail, as such now, the symlinks in the yellow area now point to themselves, aka, a never ending feedback loop.

There is no way to access the real files outisde of the jail.
N/A

CGI server fixes

So chroot doesn't look like a scalable security solution for the existing CGI server setup. And any significant change is going to to break something for someone so they're not going to be happy.

If the aim is secure hosting, why not come at the problem from the other end and add some level of user scripting support to the main homepages server, restricted to whatever can be made secure. This seems to rule out php, but if perl was available at least most things would become possible. And homepages supports SSL - something I think has been ruled out on the CGI server for ever.
N/A

CGI server fixes

Actualy, I hear that SSL is something being introduced to the CGI platform when Ben is finished.

That being said, the ifnormation I saw did not give specifics.

Chroot is used on the homepages FTP server to include some veyr reobust security. Why?

It is the scripting support of the CGI server that lets it down. When taking two access methods away (FTP and shell), you are still leaving that one behind.

There are two things I havn't looked into on the whole "securing perl" front.

1: The processing power needed to run scripts under suid (setuid) instead.

2: Does suid only apply to perl? I think it may. However, if not, then command line PHP and any other system exec based language could be used in a secure fassion.

#2 would rule out one or two functions of web-pages including persistant MySQL links (infact any persistant link) and apache and shared memory namespace access (not very usful on a load balanced platform anyhow).

I will look into this after though.