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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?08DB354F-6604-4B28-8AE9-E6B40FE87A96>