Re: [fossil-users] warning: bots injecting spam into fossil-hosted wikis

2016-01-21 Thread Richard Hipp
On 1/21/16, Stephan Beal  wrote:
>
> - make sure that the 'anonymous' user cannot write to the wiki (nor tickets
> - a prior attack targeted my ticketing system, injecting spam tickets).
>
> - use /reports?view=byuser to make sure that 'anonymous' hasn't made any
> changes. If he shows up in the /reports, follow the links there to see what
> he's done. (Maybe it's legitimate for your repo.)
>

I wonder if we could come up with a "security checklist" page of some
kind that would guide admins through these steps, and perhaps others
we have yet to think of?
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] warning: bots injecting spam into fossil-hosted wikis

2016-01-21 Thread Warren Young
On Jan 21, 2016, at 5:15 AM, Stephan Beal  wrote:
> 
> In one of the cases, someone appended non-trivial text directly relevant to 
> the (obscure) topic of the wiki page, indicating that this was (at least in 
> part) a person, not a bot.

That sounds like the default ‘m’ permission on the anonymous user.  Maybe f 
init shouldn’t do that any more?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] warning: bots injecting spam into fossil-hosted wikis

2016-01-21 Thread Warren Young
On Jan 21, 2016, at 5:21 AM, Richard Hipp  wrote:
> 
> On 1/21/16, Stephan Beal  wrote:
>> 
>> - make sure that the 'anonymous' user cannot write to the wiki
> 
> I wonder if we could come up with a "security checklist" page of some
> kind that would guide admins through these steps, and perhaps others
> we have yet to think of?

Sins of omission:

1. Not removing permissions from default users and groups before exposing the 
Fossil instance to a hostile network:

1a. anonymous: This ships as hmncz currently, but I’ll either reduce it to hnz 
or blank, depending on whether it’s a public open source project or a private 
repository.

1b. nobody: I leave the default gjorz permission set for open source projects, 
but reduce it to jr for private repos.

2. Removing permissions per 1a and 1b above, but then failing to distribute 
them:

2a. reader: May gain c and z if these were removed from anonymous.

2b. developer: Gains all permissions removed above that weren’t given to 
reader.  May also gain additional permissions besides those not removed above, 
resulting in alphabet soup flavors such as the ever popular bcdefghikmnotw.  
(Now 20% off with coupon!  Limit 3 per customer, offer ends 2/1/2016.)

3. Failing to put Fossil behind a TLS proxy if passwords may traverse an 
untrusted network.  Now that we have Let’s Encrypt, you have no more excuses.

4. Failing to keep an eye on the mailing list, to be aware of times when you 
should update to the latest Fossil.



Sins of commission:

1. Checking passwords, passphrases, symmetric encryption keys, or private 
halves of asymmetric encryption keys into a public-facing repo.

You’d never do that, of course.

Then there was the time you set up a public F/OSS project and built a pretty 
front-end web site for the parts that Fossil isn’t good at serving.  Then you 
heeded item 3 above, and used the web frontend to proxy access to the code repo 
over TLS.  And then you checked the TLS cert files into the frontend’s repo to 
make sure they get backed up.  Ooops!

Where are your DB passwords?  Code signing certs?  CI server login scripts?  
Where are the passwords you install into VMs you build with Vagrant?  Where do 
you keep the output of the system that generates software registration keys for 
customers of your trialware?  Where are the the encryption keys that make those 
registration keys unforgeable?

2. Writing commit comments, wiki articles, or tickets with comments you would 
not willingly speak to a known black hat.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] warning: bots injecting spam into fossil-hosted wikis

2016-01-21 Thread Carlo Miron
Il 21/gen/2016 22:47, "Warren Young"  ha scritto:

> 2b. developer: Gains all permissions removed above that weren’t given to
reader.  May also gain additional permissions besides those not removed
above, resulting in alphabet soup flavors such as the ever popular
bcdefghikmnotw.  (Now 20% off with coupon!  Limit 3 per customer, offer
ends 2/1/2016.)

You made my day. Thanks.

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users