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

[Jonas Smedegaard]

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

On Sun, Apr 12, 2009 at 04:44:00PM +0400, Sergey B Kirpichev wrote:
>> 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.
>
>I was wrong.  Your point is that the default configuration (static 
>html-reports) should not be in a working state since installation (log 
>parsing + web access).  So, user have to chmod/chgrp/chown/usermod 
>after a tuning of the awstats*.conf (maybe add lines in 
>/etc/cron.d/awstats too).

Indeed, I believe that default install should not indirectly expose 
adm-only information outside the adm group - which means analyzed web 
logs should not by default be readable by www-data or any other existing 
group containing non-adm users by default.

But I find in inaccurate to call it lack of "working state": If AWStats 
by default analyzes Apache2 logfiles and store the result readable only 
by adm group (or some other group not by default containing other 
members than adm group) then AWStats is in a working state!

The specific state of access from web to analyzed data is not had by 
default, that is correct, but security choices of *other* packages are 
to blame for that, not AWStats.  It is plain wrong to circumvent such 
security choices in other packages IMO.


>> >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.
>
>It means that both apache (server static pages) and CGI-script (without 
>suexec) runs with UID=www-data per default.  Permissions on $DataDir 
>or/and $DataDir/* should be same for both cases, if web access is 
>planned.  No differences.

Default apache setup use www-data for reading all web content, yes. And 
default apache setup restrict log data from being readable by www-data.

You want to obey default apache setup regarding choice of web user, 
while at the same time deliberately disobey default apache setup 
regarding access to log data.

It makes better sense to me to obey *both* parts.  Which leads us not 
choice but by default offer AWStats as two separate parts each working 
in its own rights but not working together (by default, that is):

   * log analyzer (default: output readable by adm group or by none)
   * log analysis browser (default: no data accessible to browse)

AWStats is designed without this separation: By default same config file 
is used for both tasks, requiring the backend security to be lowered.

I dare say that we should preserve the level of security established by 
default by apache and logrotate.

Which means we need to *not* use the default AWStats logic of using same 
config for both generating and browsing, if we want both to work 
out-of-the-box.

Please beware that even if both parts works out-of-the-box we cannot 
make them work together, as we still cannot by default reveal adm-only 
data to www-data.  What we can do is make it possible to configure the 
browsing part to use *other* log data that is readable by www-data.

We can then leave it tp each local admin if and how they want to combine 
the two: Change logrotate to allow www-data to read raw logdata, change 
cron job to allow www-data read access to only analyzed data, change 
apache (or setup another proxying webserver) running as a different user 
in adm group, or whatever.

But I suspect a key thing to do is to not think that same config must be 
usable for both analyzing and browsing.  AWStats should obey security 
standards, not the other way around!


>> Here's a proposal for a secure setup:
>> 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
>
>Looks too complicated.  What's wrong with my previous setup:
>
>        adduser --system --home /var/lib/awstats --shell /bin/sh --ingroup adm awstats
>        chown awstats:awstats /var/lib/awstats
>        chmod 0750 /var/lib/awstats
>?

With my proposal we only need to trust our tiny cron script running as 
root to not contain security flaws regarding access to adm data.

With your proposal we need to trust the AWStats script running as its 
own user but in adm group.

Even if AWStats is sane to rely on, imagine local admins adding custom 
unreliable plugins: They might have done so because the package did not 
put special trust into this tool.  Now we raise our trust in the tool, 
and might cause security issues at that site not wanting to put that 
much trust in the tool.


>With /etc/cron.d/awstats entry:
>
>		*/10 * * * * awstats [ -x /usr/lib/cgi-bin/awstats.pl ] && /usr/lib/cgi-bin/awstats.pl -config=awstats -update >/dev/null
>
>We have working setup per default, just no web access.
>
>Then web access is an option (as you suggest).  Thus the admin
>may use "usermod -aG awstats www-data" to serve static html-statistics.
>And use an apropriate apache.conf snippet to restrict web access.

Imagine a bug in AWStats allowing carefully crafted CGI requests to 
trigger AWStats to write something in an awstats workdir, that is then 
used by the cron job invoked with access to adm data.

This can be avoided by carefully making all awstats-owned files and 
folders only readable (not writable) by the awstats group.  But this 
requires trusting the awstats script to not be naughty and write 
something group writable - and awstats is the very script that I do not 
want to (need to) trust.

The safe approach is to ceil CGI and adm use in separate user+group, and 
have tiny routines of our own transfer between them.

...by default.  The local admin can choose to ignore all security if 
they like.



  - 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)

iEYEARECAAYFAknh/vcACgkQn7DbMsAkQLiU+QCgoDUulrdP+C0hpe3PS9NPoiQo
lFIAnROo/ppO2FRlI0FWQj0OXp3tOuDi
=hc9q
-----END PGP SIGNATURE-----