Date: Wed, 21 Feb 2007 20:31:54 +0200 From: Nikolay Pavlov <quetzal@zone3000.net> To: Stanislav Sedov <stas@FreeBSD.org> Cc: Alexis Susset <admin@munai.com>, freebsd-security@FreeBSD.org Subject: Re: Secure shared web hosting using MAC Framework Message-ID: <20070221183154.GA14590@zone3000.net> In-Reply-To: <20070221131421.1709206a.stas@FreeBSD.org> References: <E6A3BDDE-909D-4217-A773-9C8106358CD2@munai.com> <20070221131421.1709206a.stas@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. <<<-----------------------------------
======================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070221183154.GA14590>