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 [phone]
Sentex Communications, ***@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

[Dag-Erling Smørgrav]

Post by 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 ?

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

[Mike Tancsa]

Post by Dag-Erling Smørgrav

Post by 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 ?

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 [phone]
Sentex Communications, ***@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

[Poul-Henning Kamp]

Post by 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)

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.

[Dag-Erling Smørgrav]

Post by 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)

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.

DES

[Mike Tancsa]

Post by Dag-Erling Smørgrav

Post by 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)

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

Post by Dag-Erling Smørgrav
DES
--

--------------------------------------------------------------------
Mike Tancsa, tel [phone]
Sentex Communications, ***@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike