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/sunmanagersReceived on Mon Aug 19 01:10:23 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:52 EST