Hello, I would like to be able to selectively ignore sudo on some systems and not on others without being forced to just rm a conffile. The file /etc/logcheck/violations.ignore.d/logcheck-sudo (ISTM) is better placed in /etc/logcheck/ignore.d.server. THat way, a paranoid installation would still see them, but a normal one wouldn't have to. Thanks,
hello stephen, no it can't be placed there below, as security events don't have the three level filtering. easier than removing would be for your side to change it's regex so that it doesn't match any more sudo log lines. because otherwise you'll have to redo that on each upgrade. and so you'll get asked if you want to revert your change. this rule was added through popular request (see changelog for bug nr). if you give some of your users sudo access take care what you give them. i'll wait for a response from your side, but i see not much chance to changing that.
This one time, at band camp, maximilian attems said: 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. dpkg should respect the absence of a conffile as well, I would hope. It is supposed to. I see several bugs relating to regex problems in the sudo ignore, but not about the placement of the sudo ignore. 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. Thanks,
<snipp> 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. ok sorry for the noise. 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. anyway thanks for your feedback. hope there will find a resolution.
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 <debian@sternwelten.at> wrote: