Loading...
 

Tikiwiki-devel (mailman list mirror)


You are viewing a reply to Hacked tiki  

Hacked tiki

posts: 116 Germany

Yes, it was something like that. I also remember that the main issue
was the need to have write permission for the web server. One doesn’t
want to have them set during normal usage, because that could mean
havoc in case of a security hole.

So that guy suggested some way to open up the perms via FTP... not sure
how... and then have Tiki install the upgrade and remove the write
perms. This can be done by Tiki itself, so the hardening at the end of
the upgrade could be automagic, which was the thing that sold Jonny and
me on this guys idea. But yeah, details remain to be figured out.

cheers
amette

On Thu, 20 Apr 2017 16:29:44 +0100
Jonny Bradley <jonny@tiki.org> wrote:

> Oops, sorry - no, can’t remember the details, the main issue as i see
> it is that the web server process (apache etc) needs write access to
> everything, which is generally bad, so i think it was something like
> you do a chmod (of something nasty in ftp) top make everything
> web/world writable, then the updater thing runs (somehow) and then
> warns you at the end that you need to set the file perms back to
> something sensible.
>
> Something like that?
>
> jb
>
>
>
> > On 20 Apr 2017, at 11:09, Alexander Mette <mail@amette.eu> wrote:
> >
> > Sorry to necro this one, but...
> >
> > ... at FOSDEM Jonny and I talked with a guy who suggested something
> > similar. Jonny was able to grasp the whole concept, I hope he was
> > also able to memorize it until now. You might want to have a chat
> > with him regarding problems and ideas.
> >
> > cheers
> > amette
> >
> > On Wed, 21 Dec 2016 14:05:23 +0900
> > “Dr. Sassafras” <drsassafras@gmail.com> wrote:
> >
> >> So I just got one of my tiki sites hacked. It was a scratch site I
> >> used for experiments on a shared server. Hadn’t updated it in a
> >> while as it was never fresh on my mind.
> >>
> >> I’ve been toying around with the idea of coding a tiki update
> >> service, and with this recent hack I’m prioritizing it.
> >>
> >> My thought was to create a one-click system to upgrade sites to
> >> minor releases.
> >>
> >> I had a coupe ideas on how to achieve this, but right now I’m
> >> leaning toward creating a separate zip of only changed files and
> >> new database update files. The contents could be packaged in the
> >> existing directory structure so the file could be copied over the
> >> existing files, then the database update process could take place.
> >> Updating from tiki 15.0 to 15.4 would take 4 clicks, one for each
> >> minor release. If we needed to delete files, it would need to be
> >> done in a ‘database update’ file. We would also need to stop
> >> updating the copyright. Each year on minor releases.
> >>
> >> The process (download, overwrite, db update) could all happen
> >> within the tiki admin panel. We could even have tiki pre-download
> >> the update files if one is available and say something like “an
> >> update is ready for installation, click here to update tiki” or
> >> something like that.
> >>
> >> I’m thinking the update packages should only be installed through
> >> the control panel for people who don’t have a internet connection,
> >> they can drop the files in the right directory and tiki will see
> >> it and give the message about an update being ready to install.
> >>
> >> Thoughts?
> >>
> >> Brendan
> >> ------------------------------------------------------------------------------
> >> Developer Access Program for Intel Xeon Phi Processors
> >> Access to Intel Xeon Phi processor-based developer platforms.
> >> With one year of Intel Parallel Studio XE.
> >> Training and support from Colfax.
> >> Order your platform today.http://sdm.link/intel
> >> ___
> >> TikiWiki-devel mailing list
> >> TikiWiki-devel at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> >
> >
> >
> > —
> > https://amette.eu
> > mail at amette.eu
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world’s most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > TikiWiki-devel mailing list
> > TikiWiki-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> >
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world’s most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



--
https://amette.eu
mail at amette.eu

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

posts: 757 Canada

Setting permissions in ftp takes a very long time through ftp.

I would have to think (and test it out) My unix permissions knowledge is a little rusty.

However, I’m thinking that there would need to be 2 users. www user (default user for apache) which would be assigned to any file that needs write permissions, and also another user. I think it could be almost any user. but if a file is created through php, www will likely be owner. I’m not sure there is a way to strip that from the file easily,

Brendan

> On Apr 21, 2017, at 10:22 AM, Alexander Mette <mail@amette.eu> wrote:
>
> Yes, it was something like that. I also remember that the main issue
> was the need to have write permission for the web server. One doesn’t
> want to have them set during normal usage, because that could mean
> havoc in case of a security hole.
>
> So that guy suggested some way to open up the perms via FTP... not sure
> how... and then have Tiki install the upgrade and remove the write
> perms. This can be done by Tiki itself, so the hardening at the end of
> the upgrade could be automagic, which was the thing that sold Jonny and
> me on this guys idea. But yeah, details remain to be figured out.
>
> cheers
> amette
>
> On Thu, 20 Apr 2017 16:29:44 +0100
> Jonny Bradley <jonny@tiki.org> wrote:
>
>> Oops, sorry - no, can’t remember the details, the main issue as i see
>> it is that the web server process (apache etc) needs write access to
>> everything, which is generally bad, so i think it was something like
>> you do a chmod (of something nasty in ftp) top make everything
>> web/world writable, then the updater thing runs (somehow) and then
>> warns you at the end that you need to set the file perms back to
>> something sensible.
>>
>> Something like that?
>>
>> jb
>>
>>
>>
>>> On 20 Apr 2017, at 11:09, Alexander Mette <mail@amette.eu> wrote:
>>>
>>> Sorry to necro this one, but...
>>>
>>> ... at FOSDEM Jonny and I talked with a guy who suggested something
>>> similar. Jonny was able to grasp the whole concept, I hope he was
>>> also able to memorize it until now. You might want to have a chat
>>> with him regarding problems and ideas.
>>>
>>> cheers
>>> amette
>>>
>>> On Wed, 21 Dec 2016 14:05:23 +0900
>>> “Dr. Sassafras” <drsassafras@gmail.com> wrote:
>>>
>>>> So I just got one of my tiki sites hacked. It was a scratch site I
>>>> used for experiments on a shared server. Hadn’t updated it in a
>>>> while as it was never fresh on my mind.
>>>>
>>>> I’ve been toying around with the idea of coding a tiki update
>>>> service, and with this recent hack I’m prioritizing it.
>>>>
>>>> My thought was to create a one-click system to upgrade sites to
>>>> minor releases.
>>>>
>>>> I had a coupe ideas on how to achieve this, but right now I’m
>>>> leaning toward creating a separate zip of only changed files and
>>>> new database update files. The contents could be packaged in the
>>>> existing directory structure so the file could be copied over the
>>>> existing files, then the database update process could take place.
>>>> Updating from tiki 15.0 to 15.4 would take 4 clicks, one for each
>>>> minor release. If we needed to delete files, it would need to be
>>>> done in a ‘database update’ file. We would also need to stop
>>>> updating the copyright. Each year on minor releases.
>>>>
>>>> The process (download, overwrite, db update) could all happen
>>>> within the tiki admin panel. We could even have tiki pre-download
>>>> the update files if one is available and say something like “an
>>>> update is ready for installation, click here to update tiki” or
>>>> something like that.
>>>>
>>>> I’m thinking the update packages should only be installed through
>>>> the control panel for people who don’t have a internet connection,
>>>> they can drop the files in the right directory and tiki will see
>>>> it and give the message about an update being ready to install.
>>>>
>>>> Thoughts?
>>>>
>>>> Brendan
>>>> ------------------------------------------------------------------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today.http://sdm.link/intel
>>>> ___
>>>> TikiWiki-devel mailing list
>>>> TikiWiki-devel at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>>
>>>
>>> —
>>> https://amette.eu
>>> mail at amette.eu
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world’s most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> TikiWiki-devel mailing list
>>> TikiWiki-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world’s most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
>
> —
> https://amette.eu
> mail at amette.eu
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world’s most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


posts: 757 Canada

Ahh

I’m thinking he’s probably suggesting that “other users” be assigned write access after the files are deflated through ftp. I’m guessing the owner would not be www if they are deflated (or uploaded) through ftp. Then that gives php write access to everything and it can modify or harden as it sees fit, for the www user. That might work.

Maybe it would be posable to create a new user (might need admin access for that) or perhaps we could just ask that a ftp account credentials be given to the install script.

http://php.net/manual/en/book.ftp.php

You can even deflate compressed files through ftp, so that might work for updates. That way tiki can create files with a different user, prevent www from writing to files etc. Password could be stored encrypted... that might work.

Brendan

> On Apr 21, 2017, at 10:22 AM, Alexander Mette <mail@amette.eu> wrote:
>
> Yes, it was something like that. I also remember that the main issue
> was the need to have write permission for the web server. One doesn’t
> want to have them set during normal usage, because that could mean
> havoc in case of a security hole.
>
> So that guy suggested some way to open up the perms via FTP... not sure
> how... and then have Tiki install the upgrade and remove the write
> perms. This can be done by Tiki itself, so the hardening at the end of
> the upgrade could be automagic, which was the thing that sold Jonny and
> me on this guys idea. But yeah, details remain to be figured out.
>
> cheers
> amette
>
> On Thu, 20 Apr 2017 16:29:44 +0100
> Jonny Bradley <jonny@tiki.org> wrote:
>
>> Oops, sorry - no, can’t remember the details, the main issue as i see
>> it is that the web server process (apache etc) needs write access to
>> everything, which is generally bad, so i think it was something like
>> you do a chmod (of something nasty in ftp) top make everything
>> web/world writable, then the updater thing runs (somehow) and then
>> warns you at the end that you need to set the file perms back to
>> something sensible.
>>
>> Something like that?
>>
>> jb
>>
>>
>>
>>> On 20 Apr 2017, at 11:09, Alexander Mette <mail@amette.eu> wrote:
>>>
>>> Sorry to necro this one, but...
>>>
>>> ... at FOSDEM Jonny and I talked with a guy who suggested something
>>> similar. Jonny was able to grasp the whole concept, I hope he was
>>> also able to memorize it until now. You might want to have a chat
>>> with him regarding problems and ideas.
>>>
>>> cheers
>>> amette
>>>
>>> On Wed, 21 Dec 2016 14:05:23 +0900
>>> “Dr. Sassafras” <drsassafras@gmail.com> wrote:
>>>
>>>> So I just got one of my tiki sites hacked. It was a scratch site I
>>>> used for experiments on a shared server. Hadn’t updated it in a
>>>> while as it was never fresh on my mind.
>>>>
>>>> I’ve been toying around with the idea of coding a tiki update
>>>> service, and with this recent hack I’m prioritizing it.
>>>>
>>>> My thought was to create a one-click system to upgrade sites to
>>>> minor releases.
>>>>
>>>> I had a coupe ideas on how to achieve this, but right now I’m
>>>> leaning toward creating a separate zip of only changed files and
>>>> new database update files. The contents could be packaged in the
>>>> existing directory structure so the file could be copied over the
>>>> existing files, then the database update process could take place.
>>>> Updating from tiki 15.0 to 15.4 would take 4 clicks, one for each
>>>> minor release. If we needed to delete files, it would need to be
>>>> done in a ‘database update’ file. We would also need to stop
>>>> updating the copyright. Each year on minor releases.
>>>>
>>>> The process (download, overwrite, db update) could all happen
>>>> within the tiki admin panel. We could even have tiki pre-download
>>>> the update files if one is available and say something like “an
>>>> update is ready for installation, click here to update tiki” or
>>>> something like that.
>>>>
>>>> I’m thinking the update packages should only be installed through
>>>> the control panel for people who don’t have a internet connection,
>>>> they can drop the files in the right directory and tiki will see
>>>> it and give the message about an update being ready to install.
>>>>
>>>> Thoughts?
>>>>
>>>> Brendan
>>>> ------------------------------------------------------------------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today.http://sdm.link/intel
>>>> ___
>>>> TikiWiki-devel mailing list
>>>> TikiWiki-devel at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>>
>>>
>>> —
>>> https://amette.eu
>>> mail at amette.eu
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world’s most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> TikiWiki-devel mailing list
>>> TikiWiki-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world’s most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
>
> —
> https://amette.eu
> mail at amette.eu
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world’s most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.