[cobalt-security] SSH vs. .htaccess

[Dave Anders <hostmaster@xxxxxxxxxxxxx>]

> Please cut-n-paste the output of the following command:
> 
> ls -ld /home/sites/home

[admin admin]$ ls -ld /home/sites/home
drwxr-xr-x   7 admin    home         4096 Mar 13 11:15
/home/sites/home

which is CHMOD 755 and absolutely normally.

Only "admin" or "root" should be able to cd into that
/home/sites/home directory. User alfred against it 
should receive a Permission Denied response as soon as 
he tries to cd /home/sites/home

[admin admin]$ ls -ld /home/sites/site1
drwxrwsr-x   7 alfred   site1        4096 Feb 10 17:30
/home/sites/site1

drwxrwsr-x has been created by the Cobalt GUI system.
I don't understand this setting.

Each "site" comes with it's own group. The group of site1
is site1, the group of site2 is site2 ... and so on.

--Dave


> > 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.
> _______________________________________________
> cobalt-security mailing list
> cobalt-security@xxxxxxxxxxxxxxx
> http://list.cobalt.com/mailman/listinfo/cobalt-security
>