The principle of least privilege says that instead of a system full of
binaries running as root, we should have a system of binaries running as
non-root with only the capabilities they need.
The typical break-in involves gaining non-root access first, then doing a
privilege escalation attack to gain root. A system using capabilities
makes the escalation attack must more difficult.
How are we currently doing? The following (pathetically short list of)
binaries use capabilities:
vsftpd
ntptimeset
ntpdate
ntpd
named
What are the potential users of capabilities?
47 SUID root binaries (EVERYTHING install of Red Hat Linux 8.0)
Filesystem capabilities support could take care of these SUID root
binaries. Historically, SUID root binaries have been heavily used in
privilege escalation attacks.
How about daemons that are launched as root? These could be potential
users of capabilities + drop root right now.
There is a snag though. When non-root binaries (eg, daemons running as
non-root but with capabilities) execve(), all capabilities are cleared, so
if some of these daemons need to exec other binaries with certain
capabilities, it currently won't work.
"ps aux | grep root" to take a look. We see stuff like:
syslogd
cardmgr
apmd
smartd
xinetd
dhclient
gpm
crond
cupsd
anacron
rhnsd
login
mingetty
X
This is not an exhaustive list. The system I checked was not running many
daemons.
In summary, there is lots that could be done today to secure daemons. The
clearing of capabilities on exec by non-root binaries needs be addressed
(I posted a patch in May 2002). File system capabilities support can
fix the large amount of SUID root binaries that exist. OpenBSD 3.2
(just released) has started to implement a similar technique to get rid
of SUID root binaries.
Once filesystem capabilities is added to the kernel, RPM and DPKG should
be fixed so that, otherwise SUID root binaries, can be installed with
capabilities support automatically.
This should be the vendors / package maintainers job. The average sysadmin
should get the benefits without having to think about it.
Dax Kelson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:27 EST