installiing joomla

Rick Stevens ricks at alldigital.com
Tue Sep 17 00:13:40 UTC 2013


On 09/16/2013 04:44 PM, Roger issued this missive:
> On 09/16/2013 11:08 PM, Tim wrote:
>> On Sun, 2013-09-15 at 21:37 +1000, Roger wrote:
>>> I solved it by:
>>> cd /var/www/html
>>> sudo mkdir tester
>> Ugh...  Make special areas (whether they be virtual hosts, or writable
>> areas, etc.) outside of the tree.  By way of example, you don't want
>> someone to be able to navigate into a virtual host by simply appending
>> the directory name to the end of some other website address.
>>
>> e.g.  /var/www/html       (default website)
>>        /var/www/html/bad   (a badly filepathed virtual host)
>>        /var/www/better     (a better filepathed virtual host)
>>
>> Let's say the first one is www.example.com, the second one is where
>> bad.example.com is served from, and the third is better.example.com.
>>
>> I can get into bad.example.com by browsing www.example.com/bad
>>
>> That's a bad idea if they're meant to be completely independent sites.
>> It also means you need to make up extra rules, to cover filepaths and
>> URIs, for each of the ways someone could access them, if you need to
>> impose restrictions on the /bad files differently from the default
>> website.  Otherwise, someone can sidestep your rules.  And break
>> anything that relies on them using the right URIs.
>>
>> Contrariwise, I cannot get into better.example.com from any other
>> address, I have to enter it via its own address.
>>
>> As I'm sure others have explained, writable areas should be kept
>> separate, in a similar fashion (outside of the tree).  Applications that
>> write should only be able to write to their own special places.  The
>> server should read from them, probably using that application in the
>> middle, to process the data.  You don't want someone to be able to
>> directly access the data, unless it's meant to be directly accessible.
>>
>> If you have some application that insists you run your server in a
>> vulnerable manner, ditch it.  A shiny interface to a turd, is still an
>> interface to a turd.
>>
>> Way OT:  I've spent the last week surrounded by cows, sheep, and
>> woodcutters in our state fair, so haven't had a chance to do much
>> emailing.  For what it's worth, Fedora was used to reliably give the
>> counts to start our races for the last week.  Using a tiny script I
>> wrote to give the officials a one-button start/stop remote control to
>> mplayer playing an ogg file.
>>
> Thank you Tim
> Unfortunately this confuses me more.
> In basic terms, to do a test site on localhost just for messing around
> or even serious development means jumping through hoops and no  matter
> where in the system it resides, ownership and permissions make for
> vulnerability.
>
> Our commercial  ISP, one of the most globally secure and respected
> companies provides shared server /var/www/public_html where our sites
> are placed. I'm guessing this is the equivalent to /var/www/better, from
> the above example.
> I don't grasp the significance between a directory called /html or
> /better or /someothername except that httpd.conf refers to /html. It
> could equally refer to /someothername  with the same vulnerability.
>
> On a localhost there is no .com and scant likelihood of using a
> registered .com, .com.au or what ever. So I'm guessing that the dotcoms
> , etc are fictitious.

There is a difference between the _ServerRoot_ and the _DocumentRoot_.
The ServerRoot is where the server picks up its configurations and such.
The DocumentRoot is the root of the directory tree where a specific
site has its content. Where a hosting company supports virtual hosts
(VHosts), there normally are multiple DocumentRoots, each associated
with a specific VHost entry.

Both trees (the ServerRoot and all of the DocumentRoots) have to be
readable by the user that Apache runs as. Absolutely NO part of the
ServerRoot should be _writable_ by the Apache user. It should only be
writable by administrative personnel (root, people in the "wheel"
group, etc.).

Most of any given DocumentRoot tree should also not be writable by the
Apache user, but _parts_ of the DocumentRoot tree can be set to be
writable by the Apache user if Apache must store things on the local
disk (e.g. session cookies, file uploads and the like).

Doing this limits any damage to the system caused by someone hacking in
via a vulnerability in the web server code (or things like Perl or
PHP). The damage will be limited to those portions of the DocumentRoot
that were writable by the Apache user.

I hope that makes a bit more sense to you.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    ricks at alldigital.com -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-    I'm telling you that the kernel is stable not because it's a    -
-    kernel, but because I refuse to listen to arguments like this.  -
-                                              -- Linus Torvalds     -
----------------------------------------------------------------------


More information about the users mailing list