The Fedora 10 Alpha was release today, offering testers an opportunity to test drive this release and get a ‘preview’ of its new features. While reviewing the release notes, I could not help but notice the mentioning of a new Security audit tool called Sectool. Now this is something I really feel like trying!

Unfortunately I do not have a computer available for test driving Fedora 10 yet, so I decided to see what I would be able to run on Fedora 9. Fortunately according to the Fedora 10 Feature list, the new Security Audit system is a 100% integrated making me feel it’s not that big a deal to install myself.

Sectool is basically a ‘package’ addition to Fedora currently at release 0.8.5. Sectool is described as: “sectool is a security tool that can be used both as a security audit and an intrusion detection system. It consists of set of tests, library and textual/graphical frontend. Tests are sorted into groups and security levels. Admins can run selected tests, groups or whole security levels.”

Why Sectool:

  • 5 different security levels (configurations) supported
    o Naive, Desktop, Network, Server, Paranoid
  • Easy test management – each test could be assigned to one or more groups(filesystem, accounts, selinux, …)
  • Tests are language independent, written in Perl, Python, Bash, … (see Developer documentation)
  • Sectool tells you what to do if a misconfiguration is detected – hints
  • Easy to write and add new tests (see Create your own test in bash)
  • Textual and graphical user interface
  • User interface and tests can be localized
  • Sending status logs, detected differences in configuration to email. Advanced configuration of what you want see in logs, emails, etc.
  • User-friendly test configuration, creating own levels

Time to test drive it on my Fedora 9 machine!

[CaliMonk@localhost ~]$ wget https://fedorahosted.org/releases/s/e/sectool/sectool-0.8.5.tar.bz2
–2008-08-05 21:23:24– https://fedorahosted.org/releases/s/e/sectool/sectool-0.8.5.tar.bz2
Resolving fedorahosted.org… 66.135.52.17
Connecting to fedorahosted.org|66.135.52.17|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 168212 (164K) [application/x-bzip2]
Saving to: `sectool-0.8.5.tar.bz2′

100%[===========================================================================================================================================>] 168,212 156K/s in 1.1s

2008-08-05 21:23:26 (156 KB/s) – `sectool-0.8.5.tar.bz2′ saved [168212/168212]
[CaliMonk@localhost ~]$ tar -jxvf sectool-0.8.5.tar.bz2
sectool-0.8.5/
sectool-0.8.5/src/
# snip
sectool-0.8.5/sectool.console
sectool-0.8.5/sectool.desktop
[CaliMonk@localhost ~]$

Compiling…

[CaliMonk@localhost ~]$ cd sectool-0.8.5
[CaliMonk@localhost sectool-0.8.5]$ make
for d in src po doc; do make -C $d; [ $? = 0 ] || exit 1; done
make[1]: Entering directory `/home/CaliMonk/sectool-0.8.5/src’
gcc -Wall -O2 -ffast-math -I. -D_FILE_OFFSET_BITS=64 -I/usr/include/rpm sectool.c filesystem.c -lrpm -o filesystem
make[1]: Leaving directory `/home/CaliMonk/sectool-0.8.5/src’
# snip
make[1]: Entering directory `/home/CaliMonk/sectool-0.8.5/doc’
make[1]: `tests_documentation.html’ is up to date.
make[1]: Leaving directory `/home/CaliMonk/sectool-0.8.5/doc’
sed -i ‘s,APP_VERSION = \(.*\),APP_VERSION = “0.8.5″,’ ./src/sectool-gui.py
sed -i ‘s,APP_VERSION = \(.*\),APP_VERSION = “0.8.5″,’ ./src/sectool.py
[CaliMonk@localhost sectool-0.8.5]$

Finally, the make install (as root)

[CaliMonk@localhost sectool-0.8.5]$ sudo make install
[sudo] password for CaliMonk:
mkdir -p /etc
mkdir -p /etc/sectool/tests
# snip
make[1]: Entering directory `/home/CaliMonk/sectool-0.8.5/doc’
echo “Nothing to install here.”
Nothing to install here.
make[1]: Leaving directory `/home/CaliMonk/sectool-0.8.5/doc’
[CaliMonk@localhost sectool-0.8.5]$

Time to start Sectool.

[CaliMonk@localhost sectool-0.8.5]$ sudo sectool-gui

The initial interface shows all the different test the program has, including the default setting which is set to level 3 “Network”.

I’ll leave it at the default and do a test run (press ‘Start level’), you clearly see the progress at the bottom bar.

The results I was presented with show there were quite some errors (324) and warnings (3948). I find this a significant number, which can lead you to highly doubt your installation. It’s however important to notice that this tool isn’t only for security, it audits your entire system and focusses on security. Some suggestions and warnings are however more generic and do not directly affect security.

Errors it noticed:

  • The user ‘backuppc’ had a shell at ‘/usr/bin/nologin’. This is a non-existing shell, it should be ‘/sbin/nologin’
  • Shared objects that were missing (/usr/lib/libelf-0.133.so for me)
  • Files/Directories that had no existing user/groups

Warnings it noticed:

  • Disk space that was running low
  • Symbolic links pointing to non-existing files
  • Files that were group writeable and executable
  • Certain OpenSSH settings being ENABLED or DISABLED
  • Selinux being disabled
  • Shared objects that were (probably) updated

Interesting points it noticed here!

Resolving

I believe the ‘errors’ are points that definitely have to be resolved – I resolved my errors by:

  • Editing /etc/passwd and changing the path to nologin
  • I had elfutils-libelf-0.135 installed, so I symlinked. “ln -s libelf-0.135.so libelf-0.133.so”
  • chown’ing the files that had incorrect user/group ID’s (left from a tarball)

Rescanning
Rescanning my computer resulted in 0 errors (yay) but still many warnings (more even, 4002 now). As I’m not sure how it expects me to resolve warnings like “Shared objects that were (probably) updated” (which count for 3972 of my errors!), I tried the “Show hints” and “Show info” buttons.

This for me unfortunately resulted in the program hanging and ‘recovering’ after 30 seconds not showing any difference. No ‘hints’ or ‘tips’ as I would expect, leaving me not really knowing how it’s expecting me resolved the ‘warnings’.

That alone is probably based on the fact that these [Shared objects that were changed] ‘warnings’ cannot really be resolved, they are (as far as I can tell) mostly meant for ‘warning’ you. Looking at the program and the way it’s been setup you however get the impression that these are things you need to work on and try to resolve.

In this case it [Sectool] uses rpmverify to come to these conclusions [Shared objects that were changed], which just looks if files coming out of an RPM have been altered in some way. In my situation these files were indeed updated, giving me false positives in my opinion.

My conclusions so far.

This is a really interesting application, it scans your entire computer and notices many things you would normally miss. Certain errors/mistakes you’ve made it clearly points out, making it easy to directly act upon these issues. It notices settings that could/should be different, making you rethink if these settings are indeed set to what you would want.

I personally feel that the way to resolve warnings/issues should be more clear, although I understand most of these warnings and errors I would appreciate more hints as to why I should change a certain value, to what I should change this and how I should change this.

For me this was especially true for the “Shared objects that were (probably) updated” warnings, which are ‘warnings’ that cannot really be resolved from my side unlike ‘other’ warnings (i.e. the OpenSSH ones). There should be a difference between warnings you can resolve and warnings that are there to ‘warn/notice’ you.

All in all a good addition to Fedora :)

My 5 cents. (yes, 5)

Be Sociable, Share!