Re: [cobalt-users] Severe Security Problem Between Sites

["Robert G. Fisher" <rfisher@xxxxxxxxxxxxxxx>]

On Tue, Mar 28, 2000 at 07:35:58AM +0200, Michael Hoennig wrote:
> 1. Everybody has Telnet access to ALL sites!

Umm...You only have ONE server.  You don't actually telnet to
a virtual site so much as to the server it's hosted on.  The
only way you're going to get to where people don't see this is
to change the shells to something such as ksh or similiar that
allows for you to do a chroot.  That or do make the default
script call chroot as the user logs on -- this has the unfortunate
affect however that they then need a copy of lib files and basic
binaries in each site directory...Not very efficient.

> where CGI- or PHP-Skripts store data. This is because the httpd needs
> "world" rights to the files in the sites. Actually it´s at least not

Umm...httpd should never require files to be world writeable.  
Generally speaking the httpd (Apache) will run as either the
account it was started from or if started as root, as the User/Group
specified in the config files.  You can find what this is by running:

	egrep '^(User|Group) ' /etc/httpd/conf/httpd.conf

Generally speaking, files will need to be writeable by this User
or by this Group if you want FrontPage extensions to work.  Leaving
them world writeable, is often just the mark of sloppy programming
and/or configurations.

> possible to read the home directory and mail folders of others that way

Try: 'ls -l /var/spool/mail/* | less'  

Generally, the mail spool files should be owned by the user of the
same name and should be read-write by the user only.  Often, you
will see the group for the mailspool directory as mail and occasionally
some files will have read-write group permissions but this is not
required.

> - but all files which are readable by the httpd, if protected by
> .htaccess entries or not. And what especially bothers me is that scripts

.htaccess only is read by Apache (and perhaps ProFTPD), the files it
"protects" are always going to be readable by the user/group that the
server is running on since well otherwise, there'd be no files it could
read and protection for the web would be mute.  Generally this is
done by setting world permissions to read.

> are readable (skripts often have to contain passwords) and data files
> where scripts write to are even writeable.

Storing passwords in plain text...once again, a bit of slopy
programming.

> This could be solved by adding httpd to all site groups and remove the
> world-rights from all site directories and files (chmod -R o-rwx
> /home/sites/*). But I am not sure if having the httpd in all the site
> groups would raise new security leaks. And of course that breaks the
> admin UI of the cobalt.

Well, first off...This will only work if you have less than 32 
sites on your server.  32 is the maximum number of groups a user
can belong to under Linux 2.2.X and 2.0.X kernels.

What Cobalt does on the RaQ2 is it basically has all the files 
under the web and log directories owned by the httpd account.
Then on top of this, the access permissions are set with
	-rw(x)rw(x)r-- for files (x) for directories.

> I wonder why the PHP module does not at least check if the group of the
> file is the same as the group the VirtualHost is assigned too. Or why
> Apache is not calling seteuid to the User of a VirtualHost before
> calling a script (a script could not reverse that!). The only solutions
> seems to be to run PHP via CGIwrap - slower :-(

Bingo.  And, generally speaking -- Apache doesn't change uids to 
suit a virtual host, at least, I've never seen that happen.  You're
more than welcome to try editing the httpd.conf file to add the
User and Group lines to each VirtualSite, good luck, though I'd
re-check the apache docs to see if that's even valid.

> It´s easy to fix, just add the right catch-all rules to the
> /etc/virtuserlist. But again, you break the UI-only admin advantage of
> the Cobalt.

You *CAN* add the alias as 'u1@xxxxxxxxxxxxxxxxxx' -- since RaQ2,
the 'aliases' are written directly to the virtusertable.  Also,
if you look inside your virtusertable, you should find a line at
the bottom saying do not edit/remove this line, custom editions
go below here.  This would be where you can set the catch all
alias for each virtual site.

> By default there is no MySQL root passwort set, the admin is not forced
> to set one and I´ve not even found a hint to do that. So if you forget,
> problably one of your Telnet users will do that ...

This is silly, honestly, if there *IS* a default password and you
forgot, then all your telnet users would have to do is try the
documented default password and change it of their own accord.

-- 
Robert G. Fisher		     NEOCOM Microspecialists Inc. 
System Administrator/Programmer      (540) 666-9533 x 116