tripwire and device numbers

[Mike Tancsa]

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!

eg.

Rule Name: Local files (/usr/local/sbin)
Severity Level: 66
-------------------------------------------------------------------------------
----------------------------------------
Modified Objects: 10
----------------------------------------

Modified object name: /usr/local/sbin

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, mi...@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

[Poul-Henning Kamp]

In message <201003041953....@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.

[Dag-Erling Smørgrav]

Mike Tancsa <mi...@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.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Mike Tancsa]

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,

[Dag-Erling Smørgrav]

"Poul-Henning Kamp" <p...@phk.freebsd.dk> writes:

> Mike Tancsa <mi...@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.

[Mike Tancsa]

Correct. It was upset by just regular files and
directories on regular file systems in /usr/bin /sbin etc.

---Mike

>DES
>--
>Dag-Erling Smørgrav - d...@des.no

--------------------------------------------------------------------