Re: installiing joomla

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx -
- 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     -
----------------------------------------------------------------------
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org




[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux