Re: seccheck: prune directories possible?

Hi Victor!

The last update caused some new entries in "daily" checks, which seem to 
differ _every_ day ...

- fs.dentry-state = 47926       35315   45      0       0       0
+ fs.dentry-state = 69540       56902   45      0       0       0
- fs.file-nr = 1120     0       205530
- fs.inode-nr = 38051   344
- fs.inode-state = 38051        344     0       0       0       0       0
+ fs.file-nr = 1248     0       205530
+ fs.inode-nr = 50386   344
+ fs.inode-state = 50386        344     0       0       0       0       0
- kernel.random.entropy_avail = 546
+ kernel.random.entropy_avail = 752
- kernel.random.uuid = 31c93659-c328-43ca-a065-55cb6666e7d6
+ kernel.random.uuid = 26ab78db-9963-4635-9962-2e80728b8c77

A filter would be good for that :)
I'd also vote to filter specific directories out of seccheck's reach :)

br,
Markus

On Dec 16, Victor Pereira <[email protected]> wrote:

> Hi,
>
> I'm the guy maintaining the seccheck.
>
> To prune directories would be nice, however we need a more generic solution.
>
> btw I pushed some changes as suggested in bnc#904544. They are waiting
> to be approved, but they should land in factory, 13.1, 13,2 and SLE-12.
>
> The upstream I'm maintaining here https://github.com/vpereira/seccheck.
>
> patches and git pulls are always welcome :)
>
> best regards,
>
> VP
>
> On 12/03/2014 08:33 AM, Werner Flamme wrote:
>> Carlos E. R. [01.12.2014 16:06]:
>>> On 2014-12-01 15:36, Werner Flamme wrote:
>>>> Carlos E. R. [01.12.2014 15:08]:
>>>
>>>>> So the important thing to look for is that 'MNT'. It is created
>>>>> this way:
>>>> Yes, and so on, but I'd like not to modify the scripts themselves,
>>>> since they are overwritten with every update of the package, even
>>>> when it's caused by an automatic rebuild, and only the last cipher
>>>> has increased.
>>> You can wait months for an update with this modification. Even for
>>> next release cycle...
>> Depends. When I use the (newer) version from security repo, I'm in for a
>> change every few days sometimes.
>>
>>> You could add a cron job that emails you when the script has been
>>> replaced or modified, so that you can reconsider edit it back again.
>>> You can even email yourself the diff, and perhaps just replace with
>>> your copy. Or automatically undo the changes and store the update in
>>> quarantine, for your manual consideration. I don't think there are
>>> many upstream changes, though — at least, not on openSUSE. Maybe SLES
>>> is different :-?
>>>
>>> I don't see any other immediate solution for that grin ;-)
>> I try to think about something that will make manual interaction
>> unneeded, until the changes are very incompatible...
>>
>>>> [..]
>>>>> Here it produces:
>>>>>
>>>>> /dev/ / /usr /boot /home /home_aux /home1 /opt /data/storage_d
>>>>> /data/storage_b /usr/src /usr/local /data/homedvl /data/vmware
>>>>> ...
>>>>>
>>>>> I wonder about "/dev/" and "/".
>>>> I sure want security checks in those places :)
>>> Well, dev yes, but not root, because it is everything, including your
>>> backup. All the directories on the first level are printed in that
>>> command output, so "/" is not needed, unless it means just "/", not
>>> its directories.
>> If / means everything, why would the script bother to find out about
>> mountpoints at all?
>>
>> As you found out, $MNT is used by the "find" command with the option
>> "-mount", which is explained on my manpage as "Don't descend directories
>> on other filesystems.". That's why there is a need to discover
>> mountpoints at all.
>>
>> Werner
>>
>
>

-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus(at)gaugusch.at  X     Against HTML Mail
                       / \