Secure shared web hosting using MAC Framework

Momchil Ivanov idiotbg at gmail.com
Wed Feb 21 21:47:14 UTC 2007


На 21.2.2007 19:31 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?

Is this what you are looking for: 
http://www.php.net/manual/en/features.safe-mode.php

<snip>
disable_functions string 

This directive allows you to disable certain functions for security reasons. 
It takes on a comma-delimited list of function names. disable_functions is 
not affected by Safe Mode. 

This directive must be set in php.ini For example, you cannot set this in 
httpd.conf. 
disable_classes string 

This directive allows you to disable certain classes for security reasons. It 
takes on a comma-delimited list of class names. disable_classes is not 
affected by Safe Mode. 

This directive must be set in php.ini For example, you cannot set this in 
httpd.conf.
</snip>

>
> > 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.

-- 
This correspondence is strictly confidential. Any screening, filtering
and/or production for the purpose of public or otherwise disclosure is
forbidden without written permission by the author signed above. If you are
not the intended recipient, please immediately notify the sender and
permanently delete any copies

PGP KeyID: 0x3118168B
Keyserver: pgp.mit.edu
Key fingerprint BB50 2983 0714 36DC D02E  158A E03D 56DA 3118 168B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20070221/1b2422c8/attachment.pgp


More information about the freebsd-security mailing list