While getting a box ready for deployment, I noticed on two occasions, I would get some exception reports flagging all files as the underlying device number through reboots had changed. Is this "normal" for Tripwire and FreeBSD ? (RELENG_7)
The file system is on da0 at twa0 bus 0 target 0 lun 0 da0: <AMCC 9650SE-2LP DISK 4.08> Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 238408MB (488259584 512 byte sectors: 255H 63S/T 30392C) SMP: AP CPU #1 Launched!
Property: Expected Observed ------------- ----------- ----------- Object Type Directory Directory * Device Number 92 98 Inode Number 2637949 2637949 Mode drwxr-xr-x drwxr-xr-x Num Links 2 2 UID root (0) root (0) GID wheel (0) wheel (0) Size 512 512 Modify Time Wed Mar 3 15:24:02 2010 Wed Mar 3 15:24:02 2010 Blocks 4 4
---Mike
-------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
In message <201003041953.o24JrDhi038...@lava.sentex.ca>, Mike Tancsa writes:
>While getting a box ready for deployment, I noticed on two occasions, >I would get some exception reports flagging all files as the >underlying device number through reboots had changed. Is this >"normal" for Tripwire and FreeBSD ? (RELENG_7)
Yes, device numbers in freebsd carry no meaning, unless it is a compat /dev directory to boot ancient systems (SunOS, very old FreeBSD etc) diskless.
In general, tripwire should ignore devfs and possibly all pseudo-fs mount-points.
-- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Mike Tancsa <m...@sentex.net> writes: > While getting a box ready for deployment, I noticed on two occasions, > I would get some exception reports flagging all files as the > underlying device number through reboots had changed. Is this > "normal" for Tripwire and FreeBSD ?
FreeBSD does not have fixed device numbers, they are allocated on the fly as each device attaches. I don't know if there is a way around this.
>Mike Tancsa <m...@sentex.net> writes: > > While getting a box ready for deployment, I noticed on two occasions, > > I would get some exception reports flagging all files as the > > underlying device number through reboots had changed. Is this > > "normal" for Tripwire and FreeBSD ?
>FreeBSD does not have fixed device numbers, they are allocated on the >fly as each device attaches. I don't know if there is a way around >this.
OK, I think there is a way around it in the config file.
I am thinking the FreeBSD default config could be changed to
@@section FS -SEC_CRIT = $(IgnoreNone)-SHa ; # Critical files that cannot change -SEC_SUID = $(IgnoreNone)-SHa ; # Binaries with the SUID or SGID flags set -SEC_BIN = $(ReadOnly) ; # Binaries that should not change -SEC_CONFIG = $(Dynamic) ; # Config files that are changed infrequently but accessed often -SEC_TTY = $(Dynamic)-ugp ; # Tty files that change ownership at login -SEC_LOG = $(Growing) ; # Files that grow, but that should never change ownership -SEC_INVARIANT = +tpug ; # Directories that should never change permission or ownership +SEC_CRIT = $(IgnoreNone)-SHad ; # Critical files that cannot change +SEC_SUID = $(IgnoreNone)-SHad ; # Binaries with the SUID or SGID flags set +SEC_BIN = $(ReadOnly)-d ; # Binaries that should not change +SEC_CONFIG = $(Dynamic)-d ; # Config files that are changed infrequently but accessed often +SEC_TTY = $(Dynamic)-ugpd ; # Tty files that change ownership at login +SEC_LOG = $(Growing)-d ; # Files that grow, but that should never change ownership +SEC_INVARIANT = +tpug-d ; # Directories that should never change permission or ownership SIG_LOW = 33 ; # Non-critical files that are of minimal security impact SIG_MED = 66 ; # Non-critical files that are of significant security impact SIG_HI = 100 ; # Critical files that are significant points of vulnerability
Where
########################################################################### ### # Predefined Variables # ########################################################################### ### # # Property Masks # # - ignore the following properties # + check the following properties # # a access timestamp (mutually exclusive with +CMSH) # b number of blocks allocated # c inode creation/modification timestamp # d ID of device on which inode resides # g group id of owner # i inode number # l growing files (logfiles for example) # m modification timestamp # n number of links # p permission and file mode bits # r ID of device pointed to by inode (valid only for device objects) # s file size # t file type # u user id of owner # # C CRC-32 hash # H HAVAL hash # M MD5 hash # S SHA hash #
I have bcc'd the maintainer for input Thanks,
---Mike
-------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
"Poul-Henning Kamp" <p...@phk.freebsd.dk> writes: > Mike Tancsa <m...@sentex.net> writes: > > While getting a box ready for deployment, I noticed on two > > occasions, I would get some exception reports flagging all files as > > the underlying device number through reboots had changed. Is this > > "normal" for Tripwire and FreeBSD ? (RELENG_7) > Yes, device numbers in freebsd carry no meaning, unless it is a compat > /dev directory to boot ancient systems (SunOS, very old FreeBSD etc) > diskless.
> In general, tripwire should ignore devfs and possibly all pseudo-fs > mount-points.
Nothing to do with devfs; IIUC, tripwire is complaining about st.st_dev on regular files and directories.
>"Poul-Henning Kamp" <p...@phk.freebsd.dk> writes: > > Mike Tancsa <m...@sentex.net> writes: > > > While getting a box ready for deployment, I noticed on two > > > occasions, I would get some exception reports flagging all files as > > > the underlying device number through reboots had changed. Is this > > > "normal" for Tripwire and FreeBSD ? (RELENG_7) > > Yes, device numbers in freebsd carry no meaning, unless it is a compat > > /dev directory to boot ancient systems (SunOS, very old FreeBSD etc) > > diskless.
> > In general, tripwire should ignore devfs and possibly all pseudo-fs > > mount-points.
>Nothing to do with devfs; IIUC, tripwire is complaining about st.st_dev >on regular files and directories.
Correct. It was upset by just regular files and directories on regular file systems in /usr/bin /sbin etc.
-------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
