[Pkg-awstats-devel] RFC - cron-related stuff

Sat Apr 11 21:21:30 UTC 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 11, 2009 at 10:56:56PM +0400, Sergey B Kirpichev wrote:
>On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
>> >1. system user awstats (cron jobs owner) in group adm
>> 
>> Bad, when used as a CGI script: Gives writes access from anonymous 
>> web users to all adm-writable files!
>
>Wrong, just readonly access for www-data, see below (steps 2 and 3 of 
>the original RFC).

Yes, you are right: Only when executed as awstats user does it have 
access to adm group, and CGI is not (and should not!) ever run as that 
user, only the cron script.

>On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
>> AWStats analyze data that is by default readable only by admins, so 
>> our output should by default also be accessible only by admins, but 
>> optionally readable by others too.
>
>You want to access web statistics from web, isn't?

No, that is _exactly_ what I am not so sure should be the default!

>Then, it must be accessible readonly for www-data (Either generated 
>html-files or awstats data files, doesn't matter).  See below for 
>suexec-like setup.

No, I disagree: Even if(!) the output of AWStats is to be delivered 
through a web server, it should not necessarily be served to the whole 
world.  Only if it is to be served to the whole world should it be 
readable by www-data.

>We can protect CGI-script or static html-files, by some kind of HTTP 
>access control (e.g., only accessible from 127.0.0.1 by default) in 
>/usr/share/doc/awstats/examples/apache.conf.

I did susgest myself to limit access to only localhost, but thinking 
more about it I am wrong there too: Such limiting is for cases where 
content should be readable for all local users but not (by default to 
outsiders - like webservers limit access to /usr/share/doc.

The output from AWStats might be unwanted to share even with all local 
users.  It should IMO by default be accessible only by adm group (or 
some new group empty by default).  If we create a new empty group we can 
optionally offer to grant www-data access - that is not an option if we 
reuse the adm group (but we can the offer to optionally _change_ the 
group use for output).  Whatever we do, I believe the default should be 
to not expose adm content to a wider audience.

>On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
>> Those "others" might be the whole world, or it might be another 
>> limited group than admins. So it seems to me that it is better to 
>> create an awstats:awstats account (i.e. both username and groupname 
>> awstats), allowing the local admin the flexibility of either adding 
>> awstats to other groups or add other users to awstats group (without 
>> then granting them access to all other files accessible by the adm 
>> group).
>>
>> It might make sense to create yet another account 
>> awstats-cgi:awstats-cgi and make awstats member of awstats-cgi group. 
>> Cron job can then pull log files from adm group and write output 
>> accessible by CGI, without CGI script itself having access to 
>> logfiles (and other adm accessible files).
>> 
>> How does that sound?
>
>In my case others=www-data.

Nope - such other group should be a new one, to not by default in 
reality act as a leak, exposing adm content to a wider audience.

>On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
>> I have very limited time, so would appreciate if others would have a 
>> look at this.  To make it easier to follow progress, I recommend 
>> first tightening to generate static-only output, and afterwards 
>> extending with an additional CGI account (not both in same go).
>
>It's not a big difference for me.  Anyway, for static html-generated 
>files we should make $DataDir/* data accessible readonly for www-data.

Not by default.

AWStats is a web analyzer, not a proxy. On a default Debian install, 
logfiles are accessible only by adm group, and it should require an 
admin (or an admin tool) to change access rights, not a web analyzer.

>The main difference between CGI vs static stuff is just a matter of
>the awstats.pl command line parameters in /etc/cron.d/awstats ;-)

I fail to see your point.

The benefit of separating CGI from access to backend data is that 
potential bugs in the code then cannot be abused to do unusual stuff 
with backend data, e.g. read other adm-only data or edit the raw 
logfiles.

>On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
>> >2. Data files writable by awstats, readable by anyone
>> 
>> Bad: Apache2 logfiles are carefully kept readable only by adm group 
>> by default. AWStats should not defeat that by revealing its working 
>> files to the world.
>
>Wrong.  Actually, data files are readable for www-data in effect, see 
>below.
>
>On Sat, Apr 11, 2009 at 02:40:22PM +0200, Jonas Smedegaard wrote:
>> >3. DirData has group www-data & permissions 0750
>> 
>> I agree that permissions should be tightened to not be world 
>> readable. But readable by www-data is arguable somewhat equal to 
>> world readable, so that should be configurable.
> 
>Right, defaults to chmod 0750 $DirData & chown awstats:awstats $DirData 
>sounds better, see above (so, for suexec-enabled setup it may not be 
>www-data readable).  But I've no simple solution to avoid this, if the 
>static reports will be a default.

Here's a proposal for a secure setup:

1) Apache2 provides logfiles accessible only by adm group

2) Cron reads logs as root and pipes them (or cp to temp dir and chown)

3) Cron invokes awstats as awstats, saving output accessible by awstats 
group

4) Cron chmod and chown as root the output to match the input

Optionally the admin can change access right for logfiles, and our 
awstats routines will adapt.

Optionally the admin can change cron routines to use other ownership 
and/or access rights for output than that of the input.

Optionally the admin can setup a webserver to provide access to AWStats 
as some user (typically www-data, but can be other user through suexec), 
and if that user happens to have read access to the data, it will work.

We can even help the admin by providing user-friendly ways to do some of 
those optional tasks.  But we should not do any of them by default.

We should not make AWStats provide web-access to analysis of adm-only 
data out-of-the-box, only optionally!

>> >4. crontab examples (I guess, we can install awstats-update
>> >script & manpage, see bug #255938):
>> >cat >> /etc/cron.d/awstats <<EOF
>> >#MAILTO="root"
>> >#30 7 * * * awstats /usr/local/bin/awstats-update
>> >#30 7 * * * awstats /usr/lib/cgi-bin/awstats.pl -config=site.com -update > /dev/null
>> >EOF
>> 
>> Examples are examples: We do not support them, and do not use them.
>
>Ok.  But we should change www-data -> awstats in the cron.d snippet.

Why?

It is an example.  It deliberately uses "site.com" to force the admin to 
discover it and change it to something locally sane.  If by default we 
use an account having great powers, possibly too great, then the admin 
won't notice that security is weakened.

>I suggest to make a release (as you wish) before any big feature 
>changeset.  There is a number of tiny fixes/improvments.

I agree that we should release soon, and postpone complex changes. But I 
disagree that we should release without tightening security: The complex 
changes are not in securing, but in adding optional mechanisms to punch 
holes in a secure-by-default install.

So I suggest securing AWStats and then release:

  * Switch default config to only produce static content
  * Make output accessible only by awstats group (containing only awstats 
user by default)

Current packaging does not work by default

Upcoming packagin will produce data only for admins by default

Future packaging will optionally produce data for others too

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknhCdoACgkQn7DbMsAkQLg+MQCbBcohZQdLk1kyTV/m+Ho9GVPP
9G0An1PEgUqlzigXabe6+A8j1TWb1lW5
=eboc
-----END PGP SIGNATURE-----