Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Feb 2012 21:54:00 -0500
From:      mikel king <mikel.king@olivent.com>
To:        FreeBSD Questions <freebsd-questions@freebsd.org>
Subject:   Re: fbsd safety of the ports
Message-ID:  <08DB354F-6604-4B28-8AE9-E6B40FE87A96@olivent.com>
In-Reply-To: <C2DEE7E606ECCC2C0AE91F2D@mac-pro.magehandbook.com>
References:  <4F300FCD.8070804@nagual.nl> <CAHhngE0Y1hFQv4dUvaKFz68kwNWERAAJKpirTV0bvAiPmPx_aA@mail.gmail.com> <6F081A41-0EA8-4DB4-8FB9-F2E9A75EC948@olivent.com> <C2DEE7E606ECCC2C0AE91F2D@mac-pro.magehandbook.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

On Feb 7, 2012, at 9:30 PM, Daniel Staal wrote:

> --As of February 7, 2012 5:59:27 PM -0500, mikel king is alleged to =
have said:
>=20
>>=20
>> On Feb 7, 2012, at 5:15 PM, David Brodbeck wrote:
>>=20
>>> 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.
>>>>=20
>>>> 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?
>>>=20
>>> Content management systems are a bit of a sticky wicket for =
security.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> 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.
>>=20
>> Thoughts?
>=20
> --As for the rest, it is mine.
>=20
> 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...

CLI only. Absolutely no way I'd allow something like that to have web =
access. One click web crap seems nice but let's face it's not secure. =
One liners are nice too, but not so much fun for repeat business. I know =
everyone seems to be in love with one liners but my preference is the =
long term maintainability of a well documented script.=20

A well written script that backs up your db, and updates the system then =
ensuring that the correct permissions are set as you dictate seems to be =
smart. But that's just the way I'd attack it.

Unfortunately, WP isn't exactly a well designed CMS form the untaring =
standpoint.

>=20
> 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.
>=20
> 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.
>=20

Jailing is a good thought.

> User's choice at that point.  ;)
>=20
> Daniel T. Staal
>=20
> ---------------------------------------------------------------
> 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-unsubscribe@freebsd.org"





Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?08DB354F-6604-4B28-8AE9-E6B40FE87A96>