[OpenAFS] security of virtual web servers on afs

[Billy Beaudoin]

--f46d0445182d7c242b04d0abbc38
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

There are configuration options within the apache/php/vhost configs that
can mitigate some of this.  We use custom open_basedir paths on each vhost
to make sure that code within the vhost cannot escape to others.  We also
turn off exec and other commands that shell out.  And disabling symlinks.
 We also had to remove all of the web developers from having admin in the
web filesystem though, to prevent them from making mount points to other
parts of the web-accessible filesystem.

Billy Beaudoin
ITECS Systems
NC State University



On Wed, Dec 12, 2012 at 9:44 AM, Michal =C5=A0vamberg <svamberg@gmail.com> =
wrote:

> Hello,
> we are using AFS at the University of West Bohemia for virtual
> web servers. Each of them (almost 400) has its own AFS volume.
> Webserver itself has AFS identity thru IP adress and everything
> works fine. But, the problem is exactly with the AFS identity
> of webserver. It has read rights over all of virtual webservers
> and volume's owner can e.g. by PHP script read data from others
> volumes. The bigger problem is, when someone in own volume
> allow writeable rights for webserver - e.g. there is some kind
> of CMS system (Drupal, Joomla, ...) needed write rights.
> Now, attacker from outside the university can try to insert bad
> code and do with it anything he wants.
>
> Is there some reasonable advice, how to separate virtual web
> servers on AFS from each others?
>
> Thank you,
> Michal Svamberg
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>

--f46d0445182d7c242b04d0abbc38
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>There are configuration options within the apache/php/vhost configs th=
at can mitigate some of this. =C2=A0We use custom open_basedir paths on eac=
h vhost to make sure that code within the vhost cannot escape to others. =
=C2=A0We also turn off exec and other commands that shell out. =C2=A0And di=
sabling symlinks. =C2=A0We also had to remove all of the web developers fro=
m having admin in the web filesystem though, to prevent them from making mo=
unt points to other parts of the web-accessible filesystem.</div>
<div><br></div><div>Billy Beaudoin<div>ITECS Systems</div><div>NC State Uni=
versity</div></div><br>
<br><br><div class=3D"gmail_quote">On Wed, Dec 12, 2012 at 9:44 AM, Michal =
=C5=A0vamberg <span dir=3D"ltr">&lt;<a href=3D"mailto:svamberg@gmail.com" t=
arget=3D"_blank">svamberg@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
Hello,<br>
we are using AFS at the University of West Bohemia for virtual<br>
web servers. Each of them (almost 400) has its own AFS volume.<br>
Webserver itself has AFS identity thru IP adress and everything<br>
works fine. But, the problem is exactly with the AFS identity<br>
of webserver. It has read rights over all of virtual webservers<br>
and volume&#39;s owner can e.g. by PHP script read data from others<br>
volumes. The bigger problem is, when someone in own volume<br>
allow writeable rights for webserver - e.g. there is some kind<br>
of CMS system (Drupal, Joomla, ...) needed write rights.<br>
Now, attacker from outside the university can try to insert bad<br>
code and do with it anything he wants.<br>
<br>
Is there some reasonable advice, how to separate virtual web<br>
servers on AFS from each others?<br>
<br>
Thank you,<br>
Michal Svamberg<br>
<br>
_______________________________________________<br>
OpenAFS-info mailing list<br>
<a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</a><br=
>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info" target=
=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-info</a><br>
</blockquote></div><br>

--f46d0445182d7c242b04d0abbc38--