59 lines
2.5 KiB
Plaintext
59 lines
2.5 KiB
Plaintext
Overview
|
|
--------
|
|
|
|
As of Linux 2.2.0, the power of the superuser has been partitioned
|
|
into a set of discrete capabilities (in other places, these
|
|
capabilities are know as privileges).
|
|
|
|
The contents of the libcap package are a library and a number of
|
|
simple programs that are intended to show how an application/daemon
|
|
can be protected (with wrappers) or rewritten to take advantage of
|
|
this fine grained approach to constraining the danger to your system
|
|
from programs running as 'root'.
|
|
|
|
Notes on securing your system
|
|
-----------------------------
|
|
|
|
Adopting a role approach to system security:
|
|
|
|
changing all of the system binaries and directories to be owned by
|
|
some user that cannot log on. You might like to create a user with
|
|
the name 'system' who's account is locked with a '*' password. This
|
|
user can be made the owner of all of the system directories on your
|
|
system and critical system binaries too.
|
|
|
|
Why is this a good idea? In a simple case, the CAP_FUSER capabilty is
|
|
required for the superuser to delete files owned by a non-root user in
|
|
a 'sticky-bit' protected non-root owned directory. Thus, the sticky
|
|
bit can help you protect the /lib/ directory from an compromized
|
|
daemon where the directory and the files it contains are owned by the
|
|
system user. It can be protected by using a wrapper like execcap to
|
|
ensure that the daemon is not running with the CAP_FUSER capability...
|
|
|
|
|
|
Limiting the damage:
|
|
|
|
If your daemon only needs to be setuid-root in order to bind to a low
|
|
numbered port. You should restrict it to only having access to the
|
|
CAP_NET_BIND_SERVICE capability. Coupled with not having any files on
|
|
the system owned by root, it becomes significantly harder for such a
|
|
daemon to damage your system.
|
|
|
|
Note, you should think of this kind of trick as making things harder
|
|
for a potential attacker to exploit a hole in a daemon of this
|
|
type. Being able to bind to any privileged port is still a formidable
|
|
privilege and can lead to difficult but 'interesting' man in the
|
|
middle attacks -- hijack the telnet port for example and masquerade as
|
|
the login program... Collecting passwords for another day.
|
|
|
|
|
|
The /proc/ filesystem:
|
|
|
|
This Linux-specific directory tree holds most of the state of the
|
|
system in a form that can sometimes be manipulated by file
|
|
read/writes. Take care to ensure that the filesystem is not mounted
|
|
with uid=0, since root (with no capabilities) would still be able to
|
|
read sensitive files in the /proc/ tree - kcore for example.
|
|
|
|
[Patch is available for 2.2.1 - I just wrote it!]
|