control: severity -1 normal control: tags -1 - wontfix + confirmed thanks This bug is an example of the confusion and limitstions caused by the current implementation of the violations.d mechanism alongside (but with different logic and code) the 'reportlevels' choice.
I've got a proof of concept in the works that simplifies this - it allows messages relating to sudo to be filtered (as "normal") whilst also reporting any unfiltered sudo messages as more important than other rules. This would close this Will look to develop post bookworm On Tue, 5 Jul 2005 21:04:11 +0200 maximilian attems <[email protected]> wrote: > On Sat, 02 Jul 2005, Stephen Gran wrote: > > > This one time, at band camp, maximilian attems said: > <snipp> > > > no it can't be placed there below, as security events don't have the > > > three level filtering. > > > > Is that not changeable? I honestly don't know, not having looked at the > > code for logcheck. I would have thought that sudo was an expected thing > > on a multi admin machine, and not on (say) a single user desktop. So > > that is why I was thinking it made sense in a different report level. > > afaik ubuntu is using sudo for workstation/desktop and so on. > we had lots of complaint about reporting any sudo command. > we concluded that it is ok for a sudoer to exec some sys bin > and so the rules got crafted like they are. > > current logcheck code doesn't have "kicking rules" like in cracking.d > and in violations.d for the simple system events. > > > > If the report level for sudo is wrong (which it doesn't seem to be - it > > seems to be forced thre by the use of violations.d/sudo), then I guess > > it is unfixable with my idea. If it could be reported as a system event > > rather than a security event, I would love to see it moved. > > i'm not sure if it makes sense to craft an kick off dir also for the > three leveled "normal" system events nor to split the violations > in the 3 layers. not easy stuff your wish. > we need to restructure current dirs as their layout currently > is suboptimal. but i'm not in favour of adding more complexity.
