SUMMARY: /dev/mem & /dev/kmem are all readable!? Tool for files integrity & permissions check?

From: hotlist (hotlist@mmk.ru)
Date: Mon Aug 19 2002 - 01:06:34 EDT


Greetings to all SUN managers worlwide community!

Genuine Thanks to all fellows, who so quickly responded to my email!
These brave professionals are:

Casper Dik <Casper.Dik@Sun.COM>
Fabrice Guerini <fabrice@bluemartini.fr>
"Johan Hartzenberg" <jhartzen@csc.com>
"Stephen Barnett (DSL AK)" <StephenB@datacom.co.nz>
"Santos, Ramiro" <Ramiro.Santos@commerzbankib.com>
"Kevin Buterbaugh" <Kevin.Buterbaugh@lifeway.com>
Joohyun Cha <zoo11@hst.co.kr>
Scott Croft <secroft@micron.com>

And I would like to make a friendly handshake to Casper Dik for his
brief but detailed explanations. Looks like nothing changes
for the last 5 years! :)

Well, I have been originally wondering about:

I found that several Solaris 2.6 servers have "strange" permissions set
for /dev/mem and /dev/kmem special files:

crw-r--r-- 1 root sys 13, 0 <PY 18 2000 /dev/mem
crw-r--r-- 1 root sys 13, 1 <PY 18 2000 /dev/kmem

I think that these special files must not be all readable, especially
on production servers. What do you think?

SOLUTIONS
~~~~~~~~~

Running pkgchk revealed inconsistency and reported original file
permission. So I changed them to 0640.

But pkgchk also shown many ERRORS regarding other files' size & checksum.
I suppose this must be due to many patches installed on a system.

Well, it seems, that pkgchk is a very simple utility and does not
utilize any information from any patch filemaps. Should I write a
script, that would check all applied patches's files and compare their size &
checksum against installed files, or should I use tripwire - the time will
show.

Below, you may be introduced to several ideas, represented by SUN managers:

Kevin Buterbaugh
~~~~~~~~~~~~~~~~

     On my Solaris 2.6 boxes (I only have a couple left), /dev/mem and
/dev/kmem are symbolic links to the actual device files. They (the actual
device files) are not readable by all:

# ls -l /dev/*mem
lrwxrwxrwx 1 root sys 27 Jun 17 06:31 kmem ->
../devices/pseudo/mm@0:kmem
lrwxrwxrwx 1 root sys 26 Jun 17 06:31 mem ->
../devices/pseudo/mm@0:mem

And the actual devices have permissions like:
# ls -l `ls -l *mem | awk '{print $NF}'`
crw-r----- 1 root sys 13, 1 May 12 2001
../devices/pseudo/mm@0:kmem
crw-r----- 1 root sys 13, 0 Feb 12 2001
../devices/pseudo/mm@0:mem

>> The same above are acknoledged by Johan Hartzenberg & Fabrice Guerini.

Sun has the Solaris Fingerprints database, accessable (if you have a
support contract, at least) at
sunsolve.sun.com/private-cgi/fileFingerprints.pl?. You can check the
checksums on your binaries there. HTH...

Scott Croft replied with:
~~~~~~~~~~~~~~~~~~~~~~~~~

You have 2 tools you can use, one is installed with Solaris, starting
with 2.6, and that is the ASET program. Should be in /usr/aset.
The second is download a program called TIGER, which is a series of
scripts to check a system. It's default shell is bash, but because the
person who wrote it used a linux system it has /bin/sh in the top line
of the scripts and that needs to be changed to /bin/bash on a Solaris
system.

Santos Ramiro wrote:
~~~~~~~~~~~~~~~~~~~~

You may grep for your files inside "contents" under /var/sadm/install/contents.

Casper Dik suggested:
~~~~~~~~~~~~~~~~~~~~~

They should not and are not generally world readable.
The default permissions, as defined by /etc/minor_perm are:

mm:kmem 0640 root sys
mm:mem 0640 root sys

"pkgchk" uses the installed file database. tripwire generates its own.

Practically all people pointed me to Tripwire tool:

(http://sourceforge.net/projects/tripwire)
www.tripwire.org

With Best regards,
Vitaly Beliaev

mailto:hotlist@mmk.ru
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:24:48 EDT