Encontrei este post em LinuxQuestions .
Modifique para que somente partes intrerestas do proc sejam examinadas
# /proc -> $(Device) ;
/proc/sys -> $(Device) ;
/proc/cpuinfo -> $(Device) ;
/proc/modules -> $(Device) ;
Ao inicializar o banco de dados com o tripwire, digite um monte de erros referentes ao / proc:
### Warning: File system error.
### Filename: /proc/16982/fd/4
### No such file or directory
### Continuing...
### Warning: File system error.
### Filename: /proc/16982/fdinfo/4
### No such file or directory
### Continuing...
### Warning: File system error.
### Filename: /proc/16982/task/16982/fd/4
### No such file or directory
### Continuing...
### Warning: File system error.
### Filename: /proc/16982/task/16982/fdinfo/4
### No such file or directory
### Continuing...
### Warning: Duplicate object encountered.
### /proc/sys/net/ipv6/neigh
Isso parece barulho. O arquivo twpol.txt
tem a seguinte cláusula:
#
# Critical devices
#
(
rulename = "Devices & Kernel information",
severity = $(SIG_HI),
)
{
/dev -> $(Device) ;
/proc -> $(Device) ;
}
O que, se eu entendi bem, vai fazer com que o tripwire se preocupe profundamente com todo o conteúdo do / proc. Não deveria se preocupar apenas com as partes estáticas de / proc como os drivers e tal, e não o material por-pid? Por que ele é enviado assim?
Encontrei este post em LinuxQuestions .
Modifique para que somente partes intrerestas do proc sejam examinadas
# /proc -> $(Device) ;
/proc/sys -> $(Device) ;
/proc/cpuinfo -> $(Device) ;
/proc/modules -> $(Device) ;
Se isso lhe incomodar, pode modificar a sua política para excluir a pasta das verificações ...
para excluir / proc, você pode adicionar algo como:
!/proc
à sua política e reconstrua o banco de dados.