Before I publically release my new RaQ 4i to my customers I was doing a test to ensure it was indeed secure; which I am glad I did.

I setup a simulation... DomainB.com was given permission to telnet to server; however if he performed a cd /home/sites/www.domaina.com/ he gained access to the main web site! That can cause some copyright restrictions. I successfully opened the index.html file (which contains scripts for private use) from the login in domainb.com...

Is there a way to restrict this... I want the users from domainb.com to remain in www.domainb.com directory. For example, if this is site5, if the user performs 'cd /' I want them to go to the directory /home/sites/site5/. Not any further...

if the user performs 'cd /' I want them to go to the directory /home/sites/site5/

I don't know about this but, file permissions allow people to see or not see files. Honestly, unless your customers need SSH, then why give it to them? I don't.

Even with SSH disabled domainB can still get into all files... This is getting aggervating... I don't want to restric the shell from my clients, but don't want them "stealing" something there not supposed to have.

Any recommendations?

Several of the shells have "restricted" versions. They do a chroot on the users home directory and that's all the farther they can go.

I'm not sure how well this would work on a RaQ though. The users home directories are below the main "web" directory for the site. You would prob. have to do some manual "tweaking" to /etc/passwd to cange their shell and home directory.

Frank

ffeingol,

do you have any suggestions about which files to change?

It's a huge security flaw, because anyone can browse every other's files, and pick up passwords, etc.

Any suggestion is welcome.

What I did was write a stub program that is set as the user's shell. What it does is check the users's UID and GID to see if it's cool, then does a few resource locks, chroots to their home dir, changes the effective/actual UID and GID to match the user, and then executes the real shell (like /bin/sh). This has worked great for SSH, I don't allow telnet but it does the same thing.

Sadly, I hate to give out the code for serveral reasons. I don't want to be responsible if it's not perfect, plus you have to build a full mini-environment since it's in a chroot "jail." Like, have a trimmed down copy of /lib, /etc, /usr and so on in each users's home dir... But anyway what you want is a restricted shell with a chroot option or a stub like that I suppose.

AH HA! I think you emailed me about this a few days ago; I finally found it! Try this create a cron job:

--------------- BEGIN CODE -----------------------------
#!/bin/sh
/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e "/tmp,/var/tmp,/usr/tmp,/afs,/net"

---------------- END CODE -------------------------------

This should be 2 lines of code... 1. #!/bin/sh/ 2. /usr/bin.........

Hope this works!

Tommy

EDIT: Forgot one thing, don't hold me responsible for this... :) It works for me, may not work for you.

Are you sure this is the right thread? That updates the locate database, for finding files... yes? Maybe I'm in the wrong thread.

so .. ??

Any ideas thats been tested?

Even if you go through the hoops of creating a chroot environment for the shell, you're really wasting your time if you also allow CGI scripts to be run, which I assume you will, since you can still trivially access all those files in the same way.

The trick to both shell and CGI access is to use Linux file permissions correctly. The defaults used by Sun are wrong, but done so because of FrontPage, I believe.

So long as you don't have FrontPage extensions enabled on the site, then you should look at using the following file permissions:

711 on directories
500 on CGI scripts
600 on all other files files

With these permissions your sites CGI scripts should still work fine (provided your file ownerships are correct) since the RaQs use cgiwrap which executes scripts under the account that they are owned by and so you only need to enable the owner fields for access (directories still need execute access to world).

The next problem you have, however, is "training" your customers to use these permissions. It's quite common for CGI products and general help websites to say that a user should CHMOD 755 CGI scripts and CHMOD 666 (or heaven forbid 777) data files. If they do this, then your plans are of course wrecked since others can now read and most likely write :eek: to their files.

If this still isn't good enough for you, then you need to look beyond the Cobalt RaQ servers to an environment that allows you to provide Virtual Servers per customer.