Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 07 Feb 2012 21:30:20 -0500
From:      Daniel Staal <DStaal@usa.net>
To:        FreeBSD Questions <freebsd-questions@freebsd.org>
Subject:   Re: fbsd safety of the ports
Message-ID:  <C2DEE7E606ECCC2C0AE91F2D@mac-pro.magehandbook.com>
In-Reply-To: <6F081A41-0EA8-4DB4-8FB9-F2E9A75EC948@olivent.com>
References:  <4F300FCD.8070804@nagual.nl> <CAHhngE0Y1hFQv4dUvaKFz68kwNWERAAJKpirTV0bvAiPmPx_aA@mail.gmail.com> <6F081A41-0EA8-4DB4-8FB9-F2E9A75EC948@olivent.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
--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 <dick@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.
---------------------------------------------------------------



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?C2DEE7E606ECCC2C0AE91F2D>