Finding setuid binaries on Linux and BSD

Finding setuid binaries

for Linux and BSD systems

Why setuid?

Binaries with the setuid bit enabled, are being executed as if they were running under the context of the root user. This enables normal (non-privileged) users to use special privileges, like opening sockets. While this seems unnecessary for a normal user, it is actually needed for simple commands like ping.

Finding files with setuid bit

To discover all files with the setuid bit, we can use the find command. Depending on the distribution, you can use some specific parameters and special options. For example on Linux you can use -perm with slash notation (e.g. /4000). This means that if any of the file permission bits match, the result will be displayed. However, this option does not work for BSD systems, like NetBSD.

Exact match

One of the best alternatives we discovered is using the -perm parameter with the octal value. However, just providing the value, would mean we have to search for the specific mode (like 4555 in the example below).

example of finding setuid binaries

Finding setuid binaries with find command

This exact match can be useful to fix files which got incorrect permissions and are very specific. In our case this is not the case. We want all files with the setuid bit set, which means effectively “4***”. To get this type of search, we can add a dash before the octal mode. This will also match the file if the first bit is found.

As can be seen in the example, the file rcmd will match. However, instead of using -4555,  we can simplify the search to -4000. The zeros tell the find command that any of the values are fine for the other permission bits. So it will also include files which have normally 755 (or 4755).

# find /bin -perm -4000

Exclude other devices/mounts

Another useful addition to discovering the right binaries, is searching from the root. We are interested in directories like /bin, /sbin and /usr/(s)bin. Since we are not interested in files from other file systems mounted below /, we can exclude those first. This is done with the -xdev parameter.

Specific user

Now we want just the files owned by the root user. Files with root as owner in combination with setuid, are executed with root privileges. All other files are not interesting. So for to be true, we add the -user root parameter.

Setgid bit as well

To complete our search, we also want to discover files which have the similar setgid bit set. This would execute files with the permission of the group. We can do this with a logical “or” statement. So we want files with the first bit to be 4 or 2.

find / -xdev -user root \( -perm -4000 -o -perm -2000 \)

This is one of the quickest ways to search through the file system, skipping any files which are not owned by the root user and skipping device files.

What to do with the results?

Most systems will reveal a few files with the setuid or setgid bit set. So having a few on your system is not an issue, but still room for improvement. Let’s have a look at the options:

Remove the package

Sometimes we come across files which we simply don’t need on our system.

Debian / Ubuntu: dpkg -s /path/to/binary or dpkg-query -S /path/to/binary
Red Hat based systems: rpm -qf /path/to/binary

For Debian based systems with the dpkg utility, the output looks like this:

# dpkg -S /bin/mount
mount: /bin/mount

Remove the bit

Another logical option is removing the bit from the system. For example when the system has no normal users, why allow any software to use special rights? With chmod u-s we can strip the setuid bit off the file permissions. Similarly chmod g-s will remove the setgid bit.

Linux: Monitor usage with audit

If you don’t want to alter your system yet, another option would be to add the system to a Linux audit rule. This way we can track the the usage of the file.

An example to monitor the execution of binaries is with the follow Linux audit rule:

-a always,exit -F path=/bin/ps -F path=/bin/ls -F perm=x -k binaries

This rule will monitor files /bin/ps and /bin/ls and trigger an event when being executed (perm=x), with the tag binaries (k=binaries). For more information about auditing with the Audit framework, have a look at our previous post:

Configuring and auditing Linux systems with Audit daemon


Loved the article? Share your discovery:

How to check if your Arch Linux system needs a reboot

Arch Linux reboots

How to check if a reboot is needed

By default Arch will install the kernel in /boot with the name vmlinuz-linux. To determine if the system is running the latest kernel, we can compare the running kernel and the one on disk.

Running kernel

One way to determine the running kernel is with the uname command. By default installed and with the -r parameter it will provide the kernel release version.

[root@archlinux ~]# uname -r

Kernel on disk

Checking the latest kernel on disk is almost as easy. In this case we have to analyze the /boot/vmlinuz-linux file, which is the default file name for the Linux kernel on Arch Linux.

The file utility can discover the contents of the file and determine that is indeed the kernel.

[root@archlinux ~]# file /boot/vmlinuz-linux
/boot/vmlinuz-linux: Linux kernel x86 boot executable bzImage, version 3.17.4-1-ARCH (builduser@tobias) #1 SMP PREEMPT Fri Nov 21 21:1, RO-rootFS, swap_dev 0x3, Normal VGA

The interesting part in this case is the kernel version, which is behind the “version” keyword. In this case both the running kernel and kernel on disk are the same, so no reboot is needed.


If you want to automate the reboot check, we can parse the output of the uname and file commands. The small snippet below will help in performing the related check.

for I in `file /boot/vmlinuz-linux`; do
  if [ ${NEXTLINE} -eq 1 ]; then
    if [ "${I}" = "version" ]; then NEXTLINE=1; fi
if [ ! "${FIND}" = "" ]; then
  CURRENT_KERNEL=`uname -r`
  if [ ! "${CURRENT_KERNEL}" = "${FIND}" ]; then
    echo "Boot required"

Use case

Testing if systems need a reboot is especially useful as part of your software patch management strategy. In our case we have embedded this test in our auditing tool Lynis, which determines for several Linux distributions if the system needs a reboot.


Loved the article? Share your discovery:

Perform NetBSD security audit with pkg_admin

Perform NetBSD security audit

Security audit of NetBSD software packages with pkg_admin

NetBSD is especially known for it’s diverse platforms it can run on. What is less known is the ability to audit the installed packages. In this article we have a look on how to audit NetBSD and ensure the file integrity of your packages. Performing a security audit is easy, as long as you use the right tool!


When using packages, their metadata will be installed in directory within /var/db/pkg. This tree contains information about the packages.

netbsd# cd /var/db/pkg
netbsd# ls -l
total 146
drwxr-xr-x  2 root  wheel     512 Dec  3 17:23 atf-0.20
drwxr-xr-x  2 root  wheel     512 Nov 24  2013 libidn-1.28
-rw-r--r--  1 root  wheel  106391 Dec  3 17:07 pkg-vulnerabilities
drwxr-xr-x  2 root  wheel     512 Nov 24  2013 pkg_install-20130902
-rw-r--r--  1 root  wheel   28672 Dec  3 17:23 pkgdb.byfile.db
drwxr-xr-x  2 root  wheel     512 Nov 24  2013 pkgin-0.6.4nb1
drwxr-xr-x  2 root  wheel     512 Dec  3 17:23 shtk-1.4
drwxr-xr-x  2 root  wheel     512 Dec  3 17:23 sysupgrade-1.5nb1
drwxr-xr-x  2 root  wheel     512 Dec  3 17:13 wget-1.14nb3

This directory can also contain a file named pkg-vulnerabilities. This file contains information about software vulnerabilities and can be used to check what installed software packages are vulnerable.

Moving deeper

When we look into the subdirectories within /var/db/pkgs, we see a structured format of files, which include the actual metadata about the package.

# ls -l
total 78
-r--r--r--  1 root  wheel   3455 Nov 24  2013 +BUILD_INFO
-r--r--r--  1 root  wheel    398 Nov 24  2013 +BUILD_VERSION
-r--r--r--  1 root  wheel     46 Nov 24  2013 +COMMENT
-rw-r--r--  1 root  wheel   3784 Nov 24  2013 +CONTENTS
-r-xr-xr-x  1 root  wheel   4075 Nov 24  2013 +DEINSTALL
-r--r--r--  1 root  wheel    530 Nov 24  2013 +DESC
-rwxr-xr-x  1 root  wheel   9090 Nov 24  2013 +DIRS
-rwxr-xr-x  1 root  wheel  11075 Nov 24  2013 +FILES
-rwxr-xr-x  1 root  wheel   2838 Nov 24  2013 +INFO_FILES
-r-xr-xr-x  1 root  wheel  28793 Nov 24  2013 +INSTALL
-r--r--r--  1 root  wheel      8 Nov 24  2013 +SIZE_ALL
-r--r--r--  1 root  wheel      8 Nov 24  2013 +SIZE_PKG

Besides normal information (like a version number), there are actually some shell scripts. Mostly they deal with the directories, files and permissions.

Install pkg-vulnerabilities file

Before checking the system, it will need the pkg-vulnerabilities file. Installing is as easy as running the pkg_admin tool with the fetch-pkg-vulnerabilities parameter.

# pkg_admin fetch-pkg-vulnerabilities

Checking the integrity of the vulnerabilities file

The pkg_admin tool is also able to check the integrity of the fetched file. Normally it should show no output, meaning everything is fine. If not, something like this shows up:

# pkg_admin check-pkg-vulnerabilities /var/db/pkg/pkg-vulnerabilities
pkg_admin: SHA1 hash doesn't match

Running vulnerability scan

With the audit parameter we can start a vulnerability scan. It perform a security audit on the installed packages. Every package which matches a specific version, will be flagged.

screenshot of netbsd pkg_admin audit output

Discovered vulnerability in wget after running audit

Integrity check

Another thing the pkg_admin tool can perform, is an integrity check of the installed files. It uses the metadata from the packages directory and compares them with the actual files on disk.

Screen output of pkg_admin check command while performing file integrity check

pkg_admin discovered mismatches during file integrity check


This small NetBSD utility is very nifty tool and a sign that NetBSD is taking security serious as well. Happy auditing!

Loved the article? Share your discovery:

« Older Entries