Secure shared web hosting using MAC Framework

[Stanislav Sedov]

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.

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.

--
Stanislav Sedov
ST4096-RIPE
-------------- 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/58f4394d/attachment.pgp