--As of February 7, 2012 5:59:27 PM -0500, mikel king is alleged to have
said:
On Feb 7, 2012, at 5:15 PM, David Brodbeck wrote:
On Mon, Feb 6, 2012 at 9:37 AM, dick <d...@nagual.nl> wrote:
I'm a bit confused. I always believed FreeBSD is a very safe system.
That may be true for the core files, but what about ports.
On the net I read _never_ to let the webserver be the owner of its
files and yet, ports like Drupal or WordPress make the files rwx for
the owner (www) as well as the group (www). How does this fit into
fbsd's safety policy?
Content management systems are a bit of a sticky wicket for security.
The reason for not allowing the web server user to own files is so
that someone who hacks a web app can't modify the site contents. But
the whole reason for running a CMS system is to allow modifying the
site contents via a web app.
One compromise, used by TWiki and some other systems, is to make the
content writable by web processes but the actual code read-only.
That's more secure but it requires a lot of manual intervention for
updates and configuration changes. You *can* run WordPress this way,
and it will be more secure, but you'll lose the automated update
functionality as well as most of the web GUI configuration capability.
Not necessarily a problem if you have good command line fu, but it
can get tedious.
Sounds like a good area for a maintenance tool script. Run the script
prior to updates/config changes to temporarily open the permissions.
After the update has been completed rerun the script to re-secure the
permissions. Probably included a little db back in the preparation.
Thoughts?
--As for the rest, it is mine.
So, who's running the script? If it's running from the web, you haven't
actually increased your security. And if it's running from the command
line, you haven't typically saved yourself much work. (Changing the
permissions for the folders needed for an update would typically be a
one-liner, and updating manually isn't going to be much longer; a
well-designed CMS can let you do that with a single untar command.) Of
course, you could put it in cron someplace...
Of course a better solution would be to have some sort of back-end process
that the web frontend talks to, but that's a whole new layer of complexity.
(And may or may not increase security, depending on how well it's written.)
Some CMS's basically do this: They'll store all the actual pages in a
database (typically MySQL), and would only need write permissions if they
are supposed to be able to update themselves.
Balance the security, the ease of setup, the resource load, and the ease of
adminning. Sometimes the latter are worth the loss of some of the former,
if it's done well. You can always jail the webserver as well.
User's choice at that point. ;)
Daniel T. Staal
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
