[cobalt-security] SSH vs. .htaccess

[Tim Dunn <tdunn@xxxxxxxxxxxxxxxxxxx>]

> At the beginning no siteadmin or siteuser was able to "cd" into
> each site directory. Permission denied what is the default
> on Linux systems normally.

I'm not sure I agree with this.  A non-privledged user can cd
into any directory for which they have permission, based on user
or group id.  The problem with web sites is that the webserver
must also be able to read files in the directory, else it will 
not be able to serve the page.

One of the solutions I've seen is to create a separate group for
each user:

In /etc/passwd:
	username:passwordstring:12345:12345:User's Name:$HOME:$SHELL
In /etc/group:
	username::12345:username,webserver

Thus, the web server can cd into everyone's directory (subject to
.htaccess and httpd.conf restrictions), but individual users cannot
cd into one another's directory (assuming they've chmod'd their
files to u+r[w],g+r,o-rwx)

> But now every siteadmin/siteuser is even able to enter into
> /home/sites/home although ./home is owned by admin.

Please cut-n-paste the output of the following command:

	ls -ld /home/sites/home

If the permissions are group or world readable/executable, then
that is the 'correct behavior' (due to config/setup error)

> That's not normally and just a Telnet/SSH problem :-(

I suspect if you hooked up a terminal to the serial port, you'll
get the same behavior.  What you're seeing here is the standard
behavior of any *nix system.

> Websites against it can be protected by .htaccess
> And exactly that's the real problem because .htaccess
> is not working with SSH.

SSH does not respect .htaccess.  .htaccess is only for web
servers.  ssh has a host of other config files to limit/permit
specific users, machines, commands, etc.

> On the other hand it's not possible to disable SSH access
> for a domain or user by the Cobalt GUI. Shall I enter 
> /bin/false manually ?

Please consult your ssh documentation - specifically, man sshd
and look for the string "AllowUsers".  And yes, giving a user
a shell of /bin/false will work just fine as well, but it doesn't
scale well.

> As we decided to purchase Cobalt server we expected a secure,
> good working and easy to handle server system.
> 
> Now I have to do a lot of work manually and the Cobalt eMail
> support looks no longer available.

Anyone who tried to sell you any sort of server (web, email, 
whatever) by saying that you don't need to understand the basic
fundamentals of the operating system and bundled programs is
doing their company a disservice.

Anyone who tries to administer any sort of server w/o the same
basics under their belt is due for a rude shock.

tim

-- 
Mechanical Engineers build weapons.  Civil Engineers build targets.