tripwire vs. MS(MySelf) round three, on appeal
myself
using LM 7.2, kern 2.2.17-21mdk, tripwire 2.3.0-1mdk, still unable to
update policy, despite much teeth-Knashing, doc reading and mucho
patience from "elleron" in c.o.l.s from previous post.
1. install from rpm, follow instructions explicitly including modifying
default LM policy file (installed by rpm) to "fit" my system, run initial
check and db update.
2. run TW as cron job, update db as recommended (tripwire -m u -r
<reportfile>)- no errors **(except first two "file system errors")
3. run tripwire -m c -I (interactive), accept all indicated changes, no
errors **(except the first two "file system errors" as indicated below)
4. twadmin --print-polfile > mypol.txt
5. pico mypol.txt, make one change- add exclude directory rule:
"!/root/.kde/share/apps/kio_http/cache ;" in the section w/ all the other
/root rules; elleron had suggested this rule should appear above the
other /root rules, but default LM file has "!/boot/System.map ;" _below_
"/boot -> rule ;"- no problem. Anyway, tried it, didn't help.
6. tripwire --update-policy mypol.txt
(1.TW)- gathering info for new policy
examples of error messages:
**
### Warning: File system error.
### Filename: /etc/tripwire/localhost-local.key
this was never included, as TW refused to recognize a local key in format
other than K7.atl.mediaone.net
### No such file or directory
### Continuing...
### Warning: File system error.
### Filename: /etc/passwd-
### No such file or directory
indeed this is true, I deleted a temporary passwd~ file several db
updates ago, & it still complains evey time
**
### Continuing...
### Error: Policy Update Changed Object.
### An object has been changed since the database was last updated.
### Object name: Conflicting properties for object /usr/sbin
### > Modify Time
### Error: Policy Update Changed Object.
### An object has been changed since the database was last updated.
### Object name: Conflicting properties for object /usr/lib
### Error: Policy Update Changed Object.
### An object has been changed since the database was last updated.
### Object name: Conflicting properties for object /boot
### > Modify Time
### > Change Time
what do any of these have to do with my new rule? normal or
interactive checks don't indicate these, or the ones below.
### Error: Policy Update Changed Object.
### An object has been changed since the database was last updated.
### Object name: Conflicting properties for object /root
### > Num Links
### > Modify Time
### > Change Time
### An object has been changed since the database was last updated.
### Object name: Conflicting properties for object /root/.kde/share/config
### > Modify Time
### > Change Time
### Error: Policy Update Changed Object.
### An object has been changed since the database was last updated.
### Object name: Conflicting properties for object /root/tmp
### > Modify Time
### > Change Time
There are several other similar errors reported, but these are
indicative.
(2.TW) -updating db with new objects
(3.TW) -pruning unneeded objects from db
and TW exits w/ "policy update failed; policy and db files not altered".
Surely I'm an idiot and just missing something obvious, but if I can't
modify policy file, tripwire is useless :-(
BTW, what's the point of interactive check if TW forces me to accept all
changes (not removing any x's from [x]), as elleron suggested, and my
experience verifies? (if I don't accept all. TW refuses to update db)
TIA
ell...@virgil.chaos.net
[...]
> ### Warning: File system error.
> ### Filename: /etc/tripwire/localhost-local.key
> this was never included, as TW refused to recognize a local key in format
> other than K7.atl.mediaone.net
That's because the install script uses `uname -n` as the name of the
host.
> ### Continuing...
> ### Error: Policy Update Changed Object.
> ### An object has been changed since the database was last updated.
This is really the only error you're encountering, albeit in multiple
flavors. You CANNOT update the policy unless every object on disk
matches the values stored in the database. In your case:
> ### Object name: Conflicting properties for object /usr/sbin
> ### Object name: Conflicting properties for object /usr/lib
> ### Object name: Conflicting properties for object /boot
> ### Object name: Conflicting properties for object /root
> ### Object name: Conflicting properties for object /root/.kde/share/config
> ### Object name: Conflicting properties for object /root/tmp
All of which have link counts, mtimes, or ctimes on disk different
from what is stored in the database.
> Surely I'm an idiot and just missing something obvious, but if I can't
> modify policy file, tripwire is useless :-(
It is, in fact, useful _because_ you cannot update the policy file
without correcting the database. Otherwise, you could replace any
files you liked with modified versions, then update the policy to
ignore them. ie, suppose tripwire didn't complain, as you suggest:
1. Intruder installs a root kit.
2. You install a software package.
3. You edit the policy to add the package.
4. You update the policy file and tripwire adds the values for the
rootkit to the database silently.
This, and similar issues, are why it complains. What you want to do is
take the output you posted here, or a recent report (which is even
better), and print it out. (Or view it in another window).
Then, for every object, look at what changed, and see why. For
example, the mtime on /usr/sbin is changed. Most likely, because you
installed or removed software hence modifying the directory.
After you've gone through all of them, and concluded that the values
on disk are correct, and the ones stored in the database are _not_
what you want, update the database with the new values. Once there are
no files on the system that don't match the values in the database,
you can update the policy fine.
For example, suppose you installed /usr/local/hugepackage and wanted
to add a set of rules specific to it. First, you'd have to commit the
new mtime for /usr/local to the database, then update the
policy. Simiarly, if you removed it (rm -rf /usr/local/hugepackage)
you couldn't remove the rules from the policy without first accepting
the new mtime on /usr/local and all of the missing files in an
integrity check.
> BTW, what's the point of interactive check if TW forces me to accept all
> changes (not removing any x's from [x]), as elleron suggested, and my
> experience verifies? (if I don't accept all. TW refuses to update db)
It does, in fact, only update the checked ones.
One more piece of advice, and take this for whatever it's worth. I
notice you're running KDE as root. It's probably less painful if you
run tripwire either on the console, or in single user mode. If you run
it in an xterm, and get bored and play minesweeper as root, and that
happens to modify root's home directory, you'll have conflicting
objects again, even before the integrity check is done.
--
Matt Gauthier <ell...@crosswinds.net>
myself
ell...@virgil.chaos.net wrote:
Hi elleron- I was hoping that someone else would respond- not that I
don't appreciate your advice, it's just that I was afraid I'd worn you out
last go-round!
> In comp.os.linux.security myself <twofing...@atl.mediaone.net>
> wrote:
> [...]
>> ### Warning: File system error.
>> ### Filename: /etc/tripwire/localhost-local.key
>> this was never included, as TW refused to recognize a local key in
>> format other than K7.atl.mediaone.net
>
> That's because the install script uses `uname -n` as the name of the
> host.
>
OK. its not really a problem, I guess I'll just get & ignore this every
time
>> ### Continuing...
>> ### Error: Policy Update Changed Object.
>> ### An object has been changed since the database was last updated.
>
> This is really the only error you're encountering, albeit in multiple
> flavors. You CANNOT update the policy unless every object on disk
> matches the values stored in the database. In your case:
>
>> ### Object name: Conflicting properties for object /usr/sbin
>> ### Object name: Conflicting properties for object /usr/lib
>> ### Object name: Conflicting properties for object /boot
>> ### Object name: Conflicting properties for object /root
>> ### Object name: Conflicting properties for object
>> /root/.kde/share/config
>> ### Object name: Conflicting properties for object /root/tmp
>
> All of which have link counts, mtimes, or ctimes on disk different from
> what is stored in the database.
>
>> Surely I'm an idiot and just missing something obvious, but if I can't
>> modify policy file, tripwire is useless :-(
>
> It is, in fact, useful _because_ you cannot update the policy file
> without correcting the database. Otherwise, you could replace any files
> you liked with modified versions, then update the policy to ignore them.
> ie, suppose tripwire didn't complain, as you suggest:
>
Sorry if I was unclear- I'm certainly not suggesting TW not do what it's
intended to do. I'm merely saying that unless I can figure out how to
update policy file it's useless to me. AFAIK I _am_ correcting the db by
accepting the changes TW finds. Have I missed something here?
> 1. Intruder installs a root kit.
> 2. You install a software package.
> 3. You edit the policy to add the package.
> 4. You update the policy file and tripwire adds the values for the
> rootkit to the database silently.
>
> This, and similar issues, are why it complains. What you want to do is
> take the output you posted here, or a recent report (which is even
> better), and print it out. (Or view it in another window).
>
> Then, for every object, look at what changed, and see why. For example,
> the mtime on /usr/sbin is changed. Most likely, because you installed or
> removed software hence modifying the directory.
>
See, this is what I don't understand. I open konsole, run an interactive
check, make sure the changes look kosher, accept all by not removing any
x's, TW reports writing db (.twd), and then _immediately_ try to do a
policy update, which fails every time. I've tried doing db update after
TW runs as weekly cron job, specifying the report file, and then
immediately trying to do policy update, which fails. I've logged out to
terminal and run check, db update, TW reports no errors, policy update
fails. If it writes the .twd file o.k., doesn't that indicate it has
written the db to reflect the previously reported changes?
> After you've gone through all of them, and concluded that the values on
> disk are correct, and the ones stored in the database are _not_ what you
> want, update the database with the new values. Once there are no files
Isn't this what happens when I "tripwire -m u -r <reportfile>"?
or "tripwire -m c -I", no removal of x's, enter passwords as prompted,
TW writes .twd, return to prompt?
> on the system that don't match the values in the database, you can
> update the policy fine.
>
I hope you're not saying I need to iterate through -check & -update more
than once per session? Please tell me that all I really need to do is
tripwire -m c -I, accept all, tripwire --update-policy mypol.txt.
> For example, suppose you installed /usr/local/hugepackage and wanted to
> add a set of rules specific to it. First, you'd have to commit the new
> mtime for /usr/local to the database, then update the policy. Simiarly,
> if you removed it (rm -rf /usr/local/hugepackage) you couldn't remove
> the rules from the policy without first accepting the new mtime on
> /usr/local and all of the missing files in an integrity check.
>
I'm only trying to change one rule, a cache file for konqueror, original
install. When TW runs after I install or upgrade, I accept the changes,
next time it runs it seems happy (doesn't report previous changes). It
only complains when I try to update policy file.
>> BTW, what's the point of interactive check if TW forces me to accept
>> all changes (not removing any x's from [x]), as elleron suggested, and
>> my experience verifies? (if I don't accept all. TW refuses to update
>> db)
>
> It does, in fact, only update the checked ones.
>
> One more piece of advice, and take this for whatever it's worth. I
> notice you're running KDE as root. It's probably less painful if you run
> tripwire either on the console, or in single user mode. If you run it in
> an xterm, and get bored and play minesweeper as root, and that happens
> to modify root's home directory, you'll have conflicting objects again,
> even before the integrity check is done.
>
Well, as I mentioned, I did try it in runlevel 3, haven't tried it single
user. I was starting to suspect that somehow X or KDE was changing mtime
or such, but that shouldn't be a possibility from console, should it??
Anybody in a.o.l.m seen anything like this? Am I just an idiot? Hello?
Anybody out there? The folks in c.o.l.s are a swell bunch, but even
someone with the patience of a Matt Gauthier has his limits<G>.
ell...@virgil.chaos.net
>> That's because the install script uses `uname -n` as the name of the
>> host.
>>
> OK. its not really a problem, I guess I'll just get & ignore this every
> time
Well, you can change it in the configuration file. But, given your
difficulty with the policy update, maybe it's better to tackle one
situation at a time. :)
> See, this is what I don't understand. I open konsole, run an interactive
> check, make sure the changes look kosher, accept all by not removing any
> x's, TW reports writing db (.twd), and then _immediately_ try to do a
> policy update, which fails every time. I've tried doing db update after
> TW runs as weekly cron job, specifying the report file, and then
> immediately trying to do policy update, which fails. I've logged out to
> terminal and run check, db update, TW reports no errors, policy update
> fails. If it writes the .twd file o.k., doesn't that indicate it has
> written the db to reflect the previously reported changes?
Ok, in the first case, doing the policy update after accepting the
changes in a report from the cron job won't work. That's because
logging in as root changes the mtime of /root to a different value
than the one stored in the report file. (Among other files)
Dropping to runlevel 3 should've prevented some of that nonsense, but
if you're logging in and out the same thing will happen.
> I hope you're not saying I need to iterate through -check & -update more
> than once per session? Please tell me that all I really need to do is
> tripwire -m c -I, accept all, tripwire --update-policy mypol.txt.
No, if I were you, I'd boot into either single user mode, or runlevel
3 and log in just once (ie, on one tty) as root. Then do:
tripwire -m c -I
tripwire -m p mypol.txt
It is an outside possibiliy that something else broke, so you may end
up reinstalling it down the road. I'd concentrate on fixing one error
at a time now though. Since I suspect once you get one error message
gone, all the others will also vanish.
> I'm only trying to change one rule, a cache file for konqueror, original
> install. When TW runs after I install or upgrade, I accept the changes,
> next time it runs it seems happy (doesn't report previous changes). It
> only complains when I try to update policy file.
I think that's a side-effect of monitoring root's
configuration. Personally, I'd recommend not running konqueror as root
at all. ;)
> Well, as I mentioned, I did try it in runlevel 3, haven't tried it single
> user. I was starting to suspect that somehow X or KDE was changing mtime
> or such, but that shouldn't be a possibility from console, should it??
No, it shouldn't be a possibility. Unless something got left running
in the background, or you're logged in as root twice using virual
terminals. (In which case bash will monkey with your home directory
for you, no X needed.)
You, of course, don't need to go single user. You do, however, need to
be sure that you use a single root shell for both tripwire invocations
which is most easily assured by single user mode.
--
Matt Gauthier <ell...@crosswinds.net>
myself
ell...@virgil.chaos.net wrote:
> In comp.os.linux.security myself <twofing...@atl.mediaone.net>
> wrote:
>>> That's because the install script uses `uname -n` as the name of the
>>> host.
>>>
>> OK. its not really a problem, I guess I'll just get & ignore this every
>> time
>
> Well, you can change it in the configuration file. But, given your
> difficulty with the policy update, maybe it's better to tackle one
> situation at a time. :)
>
I'll second that.
>> See, this is what I don't understand. I open konsole, run an
>> interactive check, make sure the changes look kosher, accept all by not
>> removing any x's, TW reports writing db (.twd), and then _immediately_
>> try to do a policy update, which fails every time. I've tried doing db
>> update after TW runs as weekly cron job, specifying the report file,
>> and then immediately trying to do policy update, which fails. I've
>> logged out to terminal and run check, db update, TW reports no errors,
>> policy update fails. If it writes the .twd file o.k., doesn't that
>> indicate it has written the db to reflect the previously reported
>> changes?
>
> Ok, in the first case, doing the policy update after accepting the
> changes in a report from the cron job won't work. That's because logging
> in as root changes the mtime of /root to a different value than the one
> stored in the report file. (Among other files)
>
OK, this makes sense. So running TW as cron only serves to alert me of
unexpected changes. I wonder why LM includes cron but doesn't bother to
explain that its report is useless for update....
> Dropping to runlevel 3 should've prevented some of that nonsense, but if
> you're logging in and out the same thing will happen.
>
AArgh... but I'm not using a report generated prior to logging out! I log
in as root and run interactive, accept all, policy update fails, all in
the same terminal. (Sorry, frustrated w/TW, not you).
>> I hope you're not saying I need to iterate through -check & -update
>> more than once per session? Please tell me that all I really need to do
>> is tripwire -m c -I, accept all, tripwire --update-policy mypol.txt.
>
> No, if I were you, I'd boot into either single user mode, or runlevel
> 3 and log in just once (ie, on one tty) as root. Then do:
>
> tripwire -m c -I tripwire -m p mypol.txt
>
Just ran above, logged out to init 3, policy update fails.
> It is an outside possibiliy that something else broke, so you may end up
> reinstalling it down the road. I'd concentrate on fixing one error at a
> time now though. Since I suspect once you get one error message gone,
> all the others will also vanish.
>
>> I'm only trying to change one rule, a cache file for konqueror,
>> original install. When TW runs after I install or upgrade, I accept the
>> changes, next time it runs it seems happy (doesn't report previous
>> changes). It only complains when I try to update policy file.
>
> I think that's a side-effect of monitoring root's configuration.
> Personally, I'd recommend not running konqueror as root at all. ;)
>
Is that because it also functions as a browser? I'll use XWC. But I'd
still like to get this exclude rule in, surely I'll have problems
modifying policy if I can't figure out root cause of this. BTW, is it not
SOP to monitor changes to /root? Also, remember TW is complaining of
changes to other dirs e.g. /etc and /boot iirc. (or maybe this is the
side-effect you refer to?)
>> Well, as I mentioned, I did try it in runlevel 3, haven't tried it
>> single user. I was starting to suspect that somehow X or KDE was
>> changing mtime or such, but that shouldn't be a possibility from
>> console, should it??
>
> No, it shouldn't be a possibility. Unless something got left running in
> the background, or you're logged in as root twice using virual
> terminals. (In which case bash will monkey with your home directory for
> you, no X needed.)
>
> You, of course, don't need to go single user. You do, however, need to
> be sure that you use a single root shell for both tripwire invocations
> which is most easily assured by single user mode.
>
I'll try again init 3. Jobs command should show background processes,
right? Of course, there are mucho processes running anyway, I did a ps,
maybe one of those is mucking things up? Multiple shells would show as
separate or child processes, wouldn't they? As to single user, I'd have to
change a bunch of rules for that to work, as TW checks for things that
don't exist at runlevel 1.
Update- ps -aux shows one instance of bash, jobs shows nada, but I might
not <really> Know what I'm doing as I'm a GUI kinda guy. Policy update
fails :>{. This is third reinstall, using my second downloaded rpm, sure
would hate to do it again, for naught.
Gregg Morris
> In article <kD9n6.171$3F2....@typhoon.ne.mediaone.net>,
> ell...@virgil.chaos.net wrote:
>
> > In comp.os.linux.security myself <twofing...@atl.mediaone.net>
> > wrote:
> >>> That's because the install script uses `uname -n` as the name of the
> >>> host.
> >>>
> >> OK. its not really a problem, I guess I'll just get & ignore this every
> >> time
> >
> > Well, you can change it in the configuration file. But, given your
> > difficulty with the policy update, maybe it's better to tackle one
> > situation at a time. :)
> >
> I'll second that.
>
> >
> > Ok, in the first case, doing the policy update after accepting the
> > changes in a report from the cron job won't work. That's because logging
> > in as root changes the mtime of /root to a different value than the one
> > stored in the report file. (Among other files)
> >
> OK, this makes sense. So running TW as cron only serves to alert me of
> unexpected changes. I wonder why LM includes cron but doesn't bother to
> explain that its report is useless for update....
>
> >
> AArgh... but I'm not using a report generated prior to logging out! I log
> in as root and run interactive, accept all, policy update fails, all in
> the same terminal. (Sorry, frustrated w/TW, not you).
>
> >> I hope you're not saying I need to iterate through -check & -update
> >> more than once per session? Please tell me that all I really need to do
> >> is tripwire -m c -I, accept all, tripwire --update-policy mypol.txt.
> >
> >
> > tripwire -m c -I tripwire -m p mypol.txt
> >
> Just ran above, logged out to init 3, policy update fails.
>
> >
> >> I'm only trying to change one rule, a cache file for konqueror,
> >> original install. When TW runs after I install or upgrade, I accept the
> >> changes, next time it runs it seems happy (doesn't report previous
> >> changes). It only complains when I try to update policy file.
> >
I am coming into this thread in the middle, so I may be missing some
important piece of information. What I am reading is that you are
having trouble getting the policy file to update. And that you are
trying to update the twpol.txt file automagically at the same time or
after you have updated the database. It don't work that way...
It is best to start with a good twpol.txt and config file before
running your first check. However, if tw isn't hopelessly hosed and
confused you may be able to edit the twpol.txt file and create the
*real* policy file from it with tripwire -m p twpol.txt.
Once you have your policy file "/etc/tripwire/tw.pol" the way you want
it, then run your first check. Then remove the twpol.txt and the
twcfg.txt files from your harddrive and save them on a floppy.
If you can't get the policy and config files to update via this
method, you can rerun the tripwire-install script
"/etc/tripwire/twinstall" and start fresh.
I hope this helps and that I'm not leading you astray.
Gregg
--
gre...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
myself
<gre...@sdf.lonestar.org> wrote:
>> >
>
> I am coming into this thread in the middle, so I may be missing some
> important piece of information. What I am reading is that you are
> having trouble getting the policy file to update. And that you are
> trying to update the twpol.txt file automagically at the same time or
Thanks for your response...
I'm trying to update tw.pol using a modified mypol.txt file
> after you have updated the database. It don't work that way... It is
> best to start with a good twpol.txt and config file before running your
> first check. However, if tw isn't hopelessly hosed and confused you may
> be able to edit the twpol.txt file and create the
> *real* policy file from it with tripwire -m p twpol.txt.
>
LM comes with a default policy file which
requires some initial modification to suit each particular install. I've
done this, as per instructions, and subsequent checks seem to indicate
policy file matches system, ie doesn't report bogus errors. TW reports
errors when I try to modify policy which don't seem consistent with its
acceptance of db update (eg tripwire -m c -I, interactive update). Matt
has made suggestions which seem to be pointing in the right direction,
but no final resolution as of yet :-(
> Once you have your policy file "/etc/tripwire/tw.pol" the way you want
> it, then run your first check. Then remove the twpol.txt and the
> twcfg.txt files from your harddrive and save them on a floppy.
>
> If you can't get the policy and config files to update via this method,
> you can rerun the tripwire-install script
> "/etc/tripwire/twinstall" and start fresh.
>
My understanding is that re-installing TW everytime I want to change the
policy file is decidedly not the way to proceed. If you can provide some
insight into my problem, it would be greatly appreciated- please read
previous posts in this thread to understand what the problem is, as far
as my ability to express it goes. It's possible I've missed something
entirely obvious, but the initial install doesn't seem to a factor. If
you decide, after reviewing my "case", that I'm a complete idiot, I'll
humbly accept your judgement ;-}.
Gregg Morris
>
> Thanks for your response...
> I'm trying to update tw.pol using a modified mypol.txt file
OK, that sounds right.
> policy file matches system, ie doesn't report bogus errors. TW reports
> errors when I try to modify policy which don't seem consistent with its
> acceptance of db update (eg tripwire -m c -I, interactive update). Matt
> has made suggestions which seem to be pointing in the right direction,
> but no final resolution as of yet :-(
So what is the error now when you try it in single user or single console mode?
>
> My understanding is that re-installing TW everytime I want to change the
> policy file is decidedly not the way to proceed.
That's true.
I'll have to play with this a little and see if I can replicate your errors.
Gregg Morris
Here is my test:
1) I logged into a console session as root.
2) I updated the database by accepting all of the changes in the
latest report.
tripwire -m u -a -r /path/to/latest/report
/*I think you were doing an interactive update, but I think
that you will find no difference*/
3) Edit twpol.txt to bring it up to date with current system
configuration.
/*I had made some system file changes recently so I needed to do this
anyway*/
4) Update tw.pol file:
tripwire -m p /path/to/new/twpol.txt
Get good completion - no errors.
5) Try to update policy file using old (out-of-sync) policy.txt.
tripwire -m p /path/to/old/twpol.txt
6) Now the shite hits the fan:
======== Policy Update: Processing section Unix File System.
======== Step 1: Gathering information for the new policy.
### Warning: File system error.
### Filename: /var/lock/subsys/nfslock
### No such file or directory
### Continuing...
### Warning: File system error.
### Filename: /var/lock/subsys/netfs
### No such file or directory
### Continuing...
### Error: Policy Update Changed Object.
### An object has been changed since the database was last updated.
### Object name: Conflicting properties for object /root
/*I don't know why this says, "Conflicting properties for object
/root". That is misleading, I think.*/
### > Modify Time
### > Change Time
======== Step 2: Updating the database with new objects.
======== Step 3: Pruning unneeded objects from the database.
Policy update failed; policy and database files were not altered.
I think this probably looks familiar to you. If I understand what you
wrote, your _current_ mypol.txt file is not in sync with the files
that exist on your system. Find the lines that reference the
nonexisting files and comment them out. Then update the policy.
Updating the database is a separate operation from updating the
policy. The policy is just telling tripwire which files to monitor.
The database only monitors changes in those files. If the tripwire
check returns a report that says a file doesn't exist and you accept
that, you are only saying that the changes are OK. If the policy is
to check those files, the same error will turn up the next time you
look at the report.
myself
<gre...@sdf.lonestar.org> wrote:
> "myself" <twofing...@atl.mediaone.net> writes:
>
>>
>> Thanks for your response... I'm trying to update tw.pol using a
>> modified mypol.txt file
>
> OK, that sounds right.
>
>> policy file matches system, ie doesn't report bogus errors. TW reports
>> errors when I try to modify policy which don't seem consistent with its
>> acceptance of db update (eg tripwire -m c -I, interactive update). Matt
>> has made suggestions which seem to be pointing in the right direction,
>> but no final resolution as of yet :-(
>
> So what is the error now when you try it in single user or single
> console mode?
>
Running in single user mode would require many changes in policy file.
Since I can't even make _one_ change, I'd rather not go there. Single
console = runlevel 3?? If so, that's where I'm doing it since Matt made
that suggestion. Same errors. See my response to your next post.
>>
>> My understanding is that re-installing TW everytime I want to change
>> the policy file is decidedly not the way to proceed.
>
> That's true.
>
> I'll have to play with this a little and see if I can replicate your
> errors.
>
Thanks
myself
<gre...@sdf.lonestar.org> wrote:
> "myself" <twofing...@atl.mediaone.net> writes:
>
> Here is my test:
>
> 1) I logged into a console session as root.
> 2) I updated the database by accepting all of the changes in the
> latest report.
> tripwire -m u -a -r /path/to/latest/report
> /*I think you were doing an interactive update, but I think
> that you will find no difference*/
I've done it interactive, non-interactive(-m u-r), and accept all (-m u
-a -r). End result should be the same, ageeed.
> 3) Edit twpol.txt to bring it up to date with current system
> configuration.
> /*I had made some system file changes recently so I needed to do this
> anyway*/
> 4) Update tw.pol file:
> tripwire -m p /path/to/new/twpol.txt
> Get good completion - no errors.
>
> 5) Try to update policy file using old (out-of-sync) policy.txt.
> tripwire -m p /path/to/old/twpol.txt
I'm not doing that. I run interactive check, accept all changes TW
reports, print policy file w/twadmin, make one change, run policy update
which fails every time. Doesn't matter whether I run sequence in konsole
within KDE, or log out to runlevel 3.
The errors reported when I try to update policy are for files which _do_
exist- they're all essential system files eg /usr/sbin, /lib, /root,
/etc/rc.d, /boot; none of them are directly related to the change in
policy I'm trying to make (exclude a cache directory deep in /root/.kde)
except perhaps /root, but I have exclude rules for sub-directories within
monitored parent directories which don't cause problems, so I really
don't think this is an issue.
I'm going to re-install TW again. Not recommended on non-pristine system,
but all changes I've seen so far look OK, and I'm sure as hell not
re-installing LM just to get TW to work. I'm beginning to think the
problem started when I did an update using report generated in cron job-
as Matt pointed out, this report is automatically out of sync when I open
konsole to run update (changing mtimes and such). This would be obvious to
more experienced users than myself, but it would be nice if TW docs
didn't assume all users actually know what they're doing :->. Ill report
back on my progress, or lack thereof. Perhaps someone will write a TW
tutorial and include my experience under heading "Gotchas" (more likely
"Dumb Newbie Mistakes" (more likely "OK you non-sysadmin, dual-bootin',
GUI-usin' miserable sob's, if you REALLY want to play with fire, here's
EXACTLY how..."))
Thanks for your input, thanks again to Matt, thanks to group in general
for its courtesy- I didn't get a single "RTFM"!
Allan
following gets there
edit twpol.txt to suite
update policy with tripwire --update-policy -Z low twpol.txt
reinitialise tripwire
myself
<all...@removecapsiname.com> wrote:
I noticed the -Z switch in docs, but was loathe to reduce security level
on a security-oriented program, particularly since I couldn't find a
satifactory (to me) explanation of what it actually means to change this.
However.... I bit the bullet, followed your suggestion, tw reports
similar errors as before, but actually writes new policy file. Unless I
hear a compelling reason not to do it this way, this seems to do the trick.
( "compelling reason" - opinion of probably 99% of folks on this ng)
I'm still convinced I did something fundamentally wrong along the way,
which I'll try to correct in next linux install.
Thanks