On Sun, 18 Feb 2007 14:53:58 +0100
Alexis Susset <[EMAIL PROTECTED]> 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

Attachment: pgpgNfcpS722q.pgp
Description: PGP signature

Reply via email to