On 12/5/05, Russell Coker <rcoker(a)redhat.com> wrote:
On Mon, 2005-12-05 at 10:48 -0500, Linda Knippers wrote:
> > Because quota and rlimit events represent violations of system resource usage
> > policy set forth by the administrator.
>
> They aren't really violations of a policy because the operation didn't
> succeed. Its really a case of someone bumping into a resource limit.
> Isn't that why for quotas the message just goes to the user's tty
> rather than to syslog?
I think that the real issue is that quota violations are an issue of
quantity that can happen to anyone while inappropriate file access won't
happen in normal use.
If a user has a quota of 100M why should 100M of data be an audit event
while 99M isn't? Surely if you want to deal with such things then
tracking behavior and looking for anomalies is the thing to do. If a
user goes from having only 5M used fir a year to suddenly having 99M
used then it's an event that is interesting regardless of whether their
quota is 99M or 1G. It seems to me that monitoring quota is a good task
for an IDS system (which could then use the audit system to log what it
considers useful).
Would this Statistical Anomaly Detection System need to have a hold of
similar auditing calls that libaudit is looking at? On its simplest it
could do a 'du -sc $registered_directory' but would any kernel level
auditing areas be needed? This is asked from the very naive viewpoint,
that this problem could be similar to the one mentioned last month
about tracking 'audit' state of millions of files on a system inside
of a directory.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator