| View previous topic :: View next topic |
| Author |
Message |
trunet
n00b
Joined: 03 Oct 2003
Posts: 11
Location: São Paulo/SP/Brazil
|
 Posted: Wed Dec 10, 2003 6:45 pm Post subject: Tripwire policy file |
 |
|
Hi...
I saw that the /etc/tripwire/twpol.txt file is redhat based. Lot of files missing. Anyone here adapted, or created your own twpol.txt and wants to share with the community  .
Lot of work to do a brand new twpol.txt file.
Tks...
Wagner Sartori Junior |
|
| Back to top |
|
 |
squirrel
n00b
Joined: 26 Jul 2002
Posts: 20
|
| Posted: Wed Dec 17, 2003 5:40 pm Post subject: |
|
|
Hi trunet - I opened a bug for this issue.
https://bugs.gentoo.org/show_bug.cgi?id=34662
Eventually, I went through my twpol.txt and edited it to suit my box. I commented out the references for files I couldn't find, and changed the paths for the ones I could. The edited file is here (attached to bug).
https://bugs.gentoo.org/attachment.cgi?id=21520&action=view
Of course, this config is particular to my X-less box at home and may not suit yours. And I may very well not be checking some things I should be checking. I suggest you look it over carefully and alter it to better fit your setup. All the usual disclaimers apply, this file may reduce your Gentoo box to a heap of incandescent slag, etc.
Good luck with it,
squirrel |
|
| Back to top |
|
|
sven-tek
Guru
Joined: 06 May 2003
Posts: 339
|
| Posted: Sat Sep 02, 2006 7:41 pm Post subject: |
|
|
| Any chance to get an updated version? |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Fri Oct 18, 2013 12:01 pm Post subject: |
|
|
Gentoo package "mktwpol" was the eventual resolution of the bug report. mktwpol.sh creates a policy file tailored to the packages installed on any given system.
"mktwpol" is masked at this point (~x86, etc.), but if/when unmasked, is pulled in on emerge of tripwire, provided the user hasn't set "-tools" as a USE flag. |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Sat Dec 14, 2013 3:35 pm Post subject: |
|
|
mktwpol.sh -u works on an x86 install, but on an amd64 install I get
| Code: | mktwpol.sh -u
Plain-text Policy File : /etc/tripwire/twpol-131214-1515.txt ...
Using Rules File : /etc/tripwire/mktwpol-gentoo-130921.rules
Processing rule 29 of 29 tripwire policy rules
Ready to encrypt /etc/tripwire/twpol-131214-1515.txt ...
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol
Ready to make encrypted tripwire database ...
Please enter your local passphrase:
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
### Error: File seek failed.
### Filename: /proc/kcore
### Success
### Exiting...
Delete /etc/tripwire/twpol-131214-1515.txt now? [Y/n]: |
|
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Mon Dec 16, 2013 6:08 pm Post subject: Trouble with /proc/kcore |
|
|
From what I find in a search, the "seek error" from tripwire can occur if the file is too big. I don't see how that matters for /proc/kcore, because under the tripwire rule created by mktwpol, the only attributes recorded in the tripwire database are Object Type (regular file), Device Number, Inode Number, "mode" (-r--------), Number of links, UID, and GID.
But, you definitely have a problem and tripwire won't make its database until that /proc/kcore issue is resolved.
Te following changes cause tripwire to ignore /proc/kcore file.
Edit the rules file thusly:
| Code: | STOPLIST[21]='/proc/kcore'
COMMENTS_2[21]='/proc/mounts softlink undergoes time modification'
FILELIST_2[21]='/proc'
SFT_MOD_2[21]=' -mc'
RECURSE_2[21]=' (recurse = 1)' |
Brief explanation of what was done and what that causes. FILELIST_2 was changed from "/proc/*" to plain old "/proc" Under the wildcard, what is produced is a list of files and directories, the same list you get if you do `ls /proc/*` Without the wildcard, tripwire default is to recurse through all of the /proc tree, which is not desired and does lead to errors, so the added RECURSE_2 definition limits the depth of recursion.
The wildcard had to be disposed of, otherwise the specific filename /proc/kcore would be given a rule. Once it is given a rule, it can't be put on an ignorelist or stoplist.
I'm very curious what tripwire test causes the error. Before you make the changes above (which completely ignore /proc/kcore), you could try adding:
| Code: | | SEC_MOD_2[21]=' -i' |
If ignoring the inode doesn't cure the error, try
| Code: | | SEC_MOD_2[21]=' -d' |
which ignores the device number. Another possibility is to use a " -n" to skip checking the number of links to all of the files in /proc/*"
It would be possible to assign a unique tripwire test to /proc/kcore (different from the tripwire test for the other regular files in the /proc directory), but under the current script, that possibility requires the /proc directory to be handled first in a rule, instead of piggybacking. That's possible by rewriting the "Critical Devices" rule.
I have another question. Are the filesystems used to mount /proc the same on both the x86 and amd64 systems? The answer to that wouldn't change how this issue is eventually resolved, but might be useful to know. |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Wed Dec 18, 2013 1:15 am Post subject: Re: Trouble with /proc/kcore |
|
|
Thanks for the response cboldt - I tried both of your options with no joy ...
on the x86 system /proc/kcore is reported as 1016M
on the amd64 system /proc/kcore is reported as 128T somewhat larger!
The first edit worked thanks  |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Wed Dec 18, 2013 3:17 pm Post subject: Re: Trouble with /proc/kcore |
|
|
| jonathan183 wrote: | Thanks for the response cboldt - I tried both of your options with no joy ...
on the x86 system /proc/kcore is reported as 1016M
on the amd64 system /proc/kcore is reported as 128T somewhat larger!
The first edit worked thanks |
I tried that here too, and ran into false reports on /proc/[processid] directories. With the rule being written as FILELIST=/proc (instead of /proc/*), the script only puts a /proc entry in the policy file, and recursion one layer deep by tripwire (not by the script) sweeps the processid directory entries into the tripwire database. The wildcard way, the script writes policy lines for all files that are not directories, and skips the processid entries.
I might modify the script to ignore /proc files that are over some size limit. The size check would add a bit of overhead, but that can be limited to the /proc/[file] candidates. An alternative is to hard code the script to ignore /proc/kcore.
If you run into nuisance positives on /proc/[processid] entries (and I think you will), revising the script to ignore /proc/kcore while capturing all the other files in (but not directories) in the /proc directory is a simple change. Find the process_filelist () subroutine, starting at line 340 or thereabout. You'll see code that ignores the lost+found directories. Add /proc/kcore to the list of files / directories to flat out ignore.
| Code: | process_filelist ()
{
echo -e "\\n# ${RULENAME[$i]}: ${COMMENTS[$i]}\\n"
for targetfile in ${FILELIST[$i]}; do
case ${targetfile} in
*/lost+found* | /proc/kcore )
true
;; |
After you do that, revert your rules file to show FILELIST_2[21]="/proc/*" so the resulting tripwire database won't have the /proc/[processid] entries. You could either keep or delete the STOPLIST[21]='/proc/kcore' entry. It will have no effect on the tripwire database.
Thank you for the report about errors regardless of modifications to the tripwire policy (skip checking inode, for example). Seems to me to solution has to be based on a size limit, and if a file is over that limit, tripwire has to completely ignore that file when it makes its database. |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Sun Jan 05, 2014 8:18 pm Post subject: Trouble with /proc/kcore |
|
|
An improved resolution for the recent bug report has been applied to the mktwpol.sh script. The fix works for all rules, and allows /proc/kcore (and any other file) to be stoplisted from a FILELIST[] array that is built from a "*" wildcard. Rather than hard-code the script so /proc/kcore is not listed in the policy file, at all, the code below causes the script to not write any policy for any file in a STOPLIST[] array.
| Code: | process_filelist ()
{
echo -e "\\n# ${RULENAME[$i]}: ${COMMENTS[$i]}\\n"
for targetfile in ${FILELIST[$i]}; do
if [[ ! "${STOPLIST[$i]}" =~ ${targetfile} ]]; then
case ${targetfile} in
*/lost+found* )
true
;;
/proc/* )
if [ ! -d "$targetfile" ]; then
output_line; select_policy; fi
;;
* )
if [ -e "$targetfile" ]; then
output_line; select_policy; fi
;;
esac
fi
done
} |
The STOPLIST[] array is active throughout the numbered rule, affecting FILELIST[], FILELIST_2[], FILELIST_3[] and so forth. That is, there is no need for a STOPLIST_2[], STOPLIST_3[], etc., just list all stoplisted files and directories under the STOPLIST[] array. That array will prevent further listing of those files (other than as "!" entries in the tripwire policy) for all policy generated by that numbered rule.
The default rules file has been amended so that /proc/kcore is stoplisted, and the FILELIST[] is a /proc/* wildcard, so no /proc/[processid] (directory) entries appear in the generated policy.
| Code: | RULENAME[21]='Critical Devices'
COMMENTS[21]='/proc/mounts softlink undergoes time modification'
STOPLIST[21]='/proc/kcore'
FILELIST[21]='/proc/*'
SFT_MOD[21]=' -mc'
COMMENTS_2[21]='GENERIC config named kmem, mem, null, zero'
FILELIST_2[21]="/dev/kmem /dev/mem /dev/null /dev/zero \
/dev/console /dev/cua0 /dev/gpmctl /dev/initctl /dev/log /dev/port \
/dev/ppp /dev/ptyp* /dev/tty* /dev/urandom /dev/watchdog*"
SEC_MOD_2[21]=' -i' |
Those changes will appear in a future release of mktwpol-0.2.2, and are reflected in the Code section of the SourceForge repository.
The script revision allows more flexibility in writing rules, and reduces the probability of generating a defective policy file when adding a STOPLIST entry. |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Wed Jan 08, 2014 5:28 pm Post subject: STOPLIST vs. FILELIST |
|
|
That pattern matching solution just above works okay in a default configuration, but it is buggy in a more general sense.
A specific example of a bug, I have stoplisted /usr/local/sbin/mktwpol.git, which (under the code above) prevents entry of the /usr/local/sbin directory.
The code below resolves this. It has also been tested for a situation where more than one file name appears in a STOPLIST[] array. Notice the use of a variable under the `case` routine. This depends on setting the "extglob" function in bash. The mktwpol.sh script does this at initialization ...
Once the extglob function is set, a variable of the form +(first|second|third|fourth) is accepted and used by the `case` pattern matching routine. This form has a list of pipe-separated elements, with the list enclosed in parentheses. The leading "+" establishes a rule where one or more match is deemed success. The mktwpol.sh variable(s) STOPLIST[] are converted to the correct extglob form, placed in the variable $stoplist.
| Code: | process_filelist ()
{
echo -e "\\n# ${RULENAME[$i]}: ${COMMENTS[$i]}\\n"
stoplist=+\(`echo ${STOPLIST[$i]} | sed "s/ /\|/g"`\)
for targetfile in ${FILELIST[$i]}; do
case ${targetfile} in
*/lost+found* | $stoplist )
true
;;
/proc/* )
if [ ! -d "$targetfile" ]; then
output_line; select_policy; fi
;;
* )
if [ -e "$targetfile" ]; then
output_line; select_policy; fi
;;
esac
done
} |
|
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Fri Jan 10, 2014 10:06 am Post subject: Skip non-zero size /proc/* files |
|
|
Sort of a big circle back to where the /proc/kcore bug started, one more change to the mktwpol.sh script. In this revision, there is no need to STOPLIST /proc/kcore, because the process_filelist () subroutine accepts only "not non-zero size and not directory" entries. Getting rid of that logical double negative, the test accepts "zero size and not directory."
The STOPLIST vs FILELIST code remains. It is a useful test in general, even though the default rule arrangement now has no STOPLIST[] array.
| Code: | process_filelist ()
{
echo -e "\\n# ${RULENAME[$i]}: ${COMMENTS[$i]}\\n"
stoplist=+\(`echo ${STOPLIST[$i]} | sed "s/ /\|/g"`\)
for targetfile in ${FILELIST[$i]}; do
case ${targetfile} in
*/lost+found* | $stoplist )
true
;;
/proc/* )
if [ ! -d "$targetfile" -a ! -s "$targetfile" ]; then
output_line; select_policy; fi
;;
* )
if [ -e "$targetfile" ]; then
output_line; select_policy; fi
;;
esac
done
} |
The arrangement of the "Critical Devices" rule has been reverted too, since there is no intention to apply an EXCEPT[] modifier to a file in the /proc/* family. And to reiterate, /proc/kcore is not STOPLISTed because the mktwpol.sh script won't write a rule for ANY non-zero size file in the /proc/*family. Code below is in the "mktwpol*rules" file:
| Code: | RULENAME[21]='Critical Devices'
COMMENTS[21]='GENERIC config named kmem, mem, null, zero'
FILELIST[21]="/dev/kmem /dev/mem /dev/null /dev/zero \
/dev/console /dev/cua0 /dev/gpmctl /dev/initctl /dev/log /dev/port \
/dev/ppp /dev/ptyp* /dev/tty* /dev/urandom /dev/watchdog*"
SEC_MOD[21]=' -i'
COMMENTS_2[21]='/proc/mounts softlink undergoes time modification'
FILELIST_2[21]='/proc/*'
SFT_MOD_2[21]=' -mc' |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
