Secure shared web hosting using MAC Framework

[Nikolay Pavlov]

On Wednesday, 21 February 2007 at 13:14:21 +0300, Stanislav Sedov wrote:
> On Sun, 18 Feb 2007 14:53:58 +0100
> Alexis Susset <admin at munai.com> mentioned:
> 
> > Hi all,
> >
> > I am looking at securing a web server using the FreeBSD MAC Framework.
> >
> > To make things clear I will call the hosted users "web users". Those
> > are the issues I am dealing with:
> >
> > ** Network Security **
> > - Web users shouldn't be able to connect to reserved local ports
> > apart from 25(smtp); 80(http); 443(https) and 3306(MySQL)
> >     Solution:
> > 	run the web server and web users shell in a jail, use ipfw to limit
> > the jail access to localhost
> > 	Those are the rules I have set:
> > 		${fwcmd} add 60 pass ip from any to any dst-port 25 jail 1 via lo0
> > 		${fwcmd} add 61 pass ip from any to any dst-port 80 jail 1 via lo0
> > 		${fwcmd} add 62 pass ip from any to any dst-port 443 jail 1 via lo0
> > 		${fwcmd} add 63 pass ip from any to any dst-port 3306 jail 1 via lo0
> > 		${fwcmd} add 80 deny ip from any to any jail 1 via lo0
> > 	Here, I allow 80 and 443 in case the users want to locally use some
> > web APi. MySQL and smtp use are obvious.
> >
> > - Web users shouldn't be able to open any socket, but, they should
> > still be able to connect to the outside
> >      This is where I do not have a solution.
> > 	I think the use of mac_bsdextended would work here, but there are no
> > clear way of doing this.
> > 	Anyone has a good configuration in place ?
> >
> 
> You can use mac_portacl or net.inet.ip.portrange.reserved{high,low} to
> deny users from opening listening sockets.
> 
> >
> > ** Resources Security **
> >      Solution:
> > 	This is a straight forward one, configure login.conf and the virtual
> > hosts with resources limits.
> > 	This can be adjusted for specific user who may need more than usual.
> >
> 
> This isn't so straightforward as you can think. At least you should
> ensure all apps correctly initializes pam_session (e.g. suexec doesn't
> do that). Same for cron.
> 
> >
> > ** File System Security **
> > - Jail Security
> >      Solution:
> > 	Build the jail with only required files, this is done via make.conf
> > 	Deny access
> >
> 
> You can probably use read-only nullfs mounts to disallow file
> modifications inside jails.
> 
> > - Web users and executed web scripts shouldn't be able to read other
> > users data
> >      Solution:
> > 	run suPHP for php scripts as well as suEXEC for cgi-scripts
> > 	implement ufs_acl so that the www (Web Server) user can access any
> > user directory
> > 	Add a ufs_acl to the Web users home directory which says:
> > 		read-write-exec only from $owner and www
> > 	Those rights should have priority on any traditional unix file
> > system rights.
> 
> I believe the suphp will be a amazingly slow solution as it executes
> php executable on each request, IIRC. Thus, the speed will not be
> faster then php in cgi.

But is there any way to disbale related php functions? is there any well
defined configuration examples for mod_php?

> 
> Regarding acls - you should also develop some solution, that allows
> acls to be inherited, as your users will complain when their newly
> created files will be unreadable by web-server (they will not set
> acls by hand, as you can see). The better solution will be probably to
> allow web-server group to read all files owned by users (via umask)
> and than separate users from each other via bsd_extended.
> 
> >
> > - For the user's own security, prevent them from writing to /tmp
> >      Solution:
> > 	add a ufs_acl rule to /tmp, this should be read only (for mysql
> > socket and other things that might reside here)
> >
> > - As much as possible, web users should have a limited view of the
> > systems
> >     Solution:
> > 	use the follwing sysctl variable
> > 		security.bsd.see_other_uids=0
> > 		security.bsd.unprivileged_read_msgbuf=0
> > 	Since the web users are in a jail, set restricted devfs ruleset
> > (this is easily done via rc.conf)
> > 		jail_web_devfs_enable="YES"
> > 		jail_web_devfs_ruleset="devfsrules_jail"
> >
> > - Web users and executed web scripts shouldn't be able to read
> > important system files
> >      Solution:
> > 	use ufs_acl to prevent the users from accessing the following:
> > 		/boot /root
> > 		/sbin /usr/sbin /usr/local/sbin
> > 		/var
> > 		/etc/(apart from resolv.conf, group, hosts, pwd.db, nsswitch.conf,
> > services, mailer.conf, ssh/ssh_config and mail/)
> > 		/usr/local/etc (appart from tools/configs which are normally
> > required by the user. eg: nss-ldap)
> > 	Those rights should have priority on any traditional unix file
> > system rights.
> > 	I could make a longer list, this one's just ot get started.
> > 	I am sure there's a better way to do that, maybe a MAC ruleset
> > already exists for that, has anyone done that already?
> >
> > - Web users should be able to access their own crontab
> >      Solution: use ufs_acl to give rights to the crontab directory
> >
> > - Web users should be able to send emails
> >      Solution: use ufs_acl to give rights to the mail spool
> >
> > - Web users shouldn't be able to install binaries but still be able
> > to install CGi scripts
> >      This is where I do not have a solution.
> > 	Has anyone implemented such policy?
> 
> How will you differ CGI scripts and binaries? Binaries effectively cgi
> scripts too.

This is possible to use pure-ftpd upload script with some file utility
magic, but this is only for ftp access of course.

-- 
======================================================================  
- Best regards, Nikolay Pavlov. <<<-----------------------------------    
======================================================================