Quote:
Originally Posted by pinga123
Being a production system i want to implement the same on our server.
|
The document is from 2006 and was updated last in 2007. It is marked "Internal Distribution Only" which might signify Stanford-specific policies and support for systems and users of the guide. Also note the document offers compliance with several standards like DISA STIG. Determine if that kind of standards compliance is what you are actually after. Next to your distributions documentation on system hardening a high level document you might want to read is
Twenty Critical Controls for Effective Cyber Defense: Consensus Audit Guidelines and for practically making changes the
CIS Red Hat Enterprise Linux 5 Benchmark (CIS). Also see the
LQ FAQ: Security references (or the cleaned print version at
http://rkhunter.wiki.sourceforge.net/SECREF?f=print) wrt systems hardening resources, GNU/Tiger, OWASP, OpenVAS and OAT.
Quote:
Originally Posted by pinga123
and more important will it impact on rest of the sytem?
|
Do realize that next to your distributions documentation on system hardening there are complete websites dedicated to Linux security (like SANS) and Security standards (like NIST) and tools and methods exist to help determine necessity:
- running 'rpm -qf /path/to/binary' will show you which package the binary belongs to,
- running 'rpm -qi' on the package name will tell you in short what the package is for,
- running 'rpm -q --whatrequires package name' may indicate what other packages require your package,
- grepping your /var/log/{messages,secure} for PAM stack messages related to authorization for use of setuid binaries may indicate use, and
- grepping your /var/log/audit/audit.log may indicate use.
- Ask yourself for each file "which user except root requires to perform task X" (say change shell, mount file system?).
- Determine for each file if there exist controls to restrict usage (for instance: PAM, /etc/{at,cron}.allow).
- Determine for each file or package if the
CVE lists unacceptable risks or security track record.
- Ask yourself for each package that requires your package if it is required for basic system operation (a server in most cases runs headless, in runlevel 3 and does not require X11 or Xorg).
- Ask yourself for each package if it is required for basic system operation (say ping6 if you don't run IPv6).
Running the above you will find a large portion of the files you listed are part of vital system packages like initscripts, shadow-utils, pam, util-linux, sudo and coreutils but some are not clear. Example: /lib/dbus-1/dbus-daemon-launch-helper.
Who owns and what is this file?:
Code:
stat -c "%a %U %G %F" /lib/dbus-1/dbus-daemon-launch-helper
4750 root dbus regular file
So it's a regular file (binary here) setuid-root and group dbus.
What is this group dbus?
Code:
getent group dbus
dbus:x:81:
Group has a GID below 500 (/etc/login.defs) meaning it's an account used by only the system itself.
Which package does the file belong to:
Code:
rpm -qf /lib/dbus-1/dbus-daemon-launch-helper
dbus
What group is this package in:
Code:
rpm -q dbus --qf="%{NAME}, %{GROUP}\n"
dbus, System Environment/Libraries
It reads "System Environment/Libraries" so removing this may reduce or damage operating capability.
Which package requires that package:
Code:
rpm -q --whatrequires dbus --qf="%{name}\n"
setroubleshoot-plugins setroubleshoot dbus-libs hal avahi
Which packages requires the package that requires this package:
Code:
rpm -q --whatrequires dbus --qf="%{name}\n"|while read PKG; do echo "${PKG}: $(rpm -q --whatrequires ${PKG} --qf="%{name}\n"| xargs)"; done
setroubleshoot-plugins: setroubleshoot-server setroubleshoot
setroubleshoot: no package requires setroubleshoot
dbus-libs: dbus
hal: kudzu
avahi: avahi-qt3 avahi-glib avahi-compat-libdns_sd
Answering the questions:
- Which user except root requires to perform task X? None, it's a system user.
- Do controls exist to restrict usage? Yes, 'getent passwd dbus' returns shell as /sbin/nologin (inert account).
- Does the CVE lists unacceptable risks or security track record? Latest was
585394, acknowledged as
CVE-2010-1172 and fixed by
RHSA-2010:0616 (Also see OVAL, ovaldi).
- Requires required for basic system operation? HAL and D-BUS are both subsystems and should not be removed. setroubleshoot can be replaced by root regularly running 'ausearch' and 'audit2allow < /var/log/audit/audit.log' from the command line or a cronjob. Avahi is only necessary if your setup requires that kind of network service discovery.
HTH and good luck.
