blob: cfad4c003ecdd2d0318ddd9c4c1e1da3a05eda7e (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
# Notes concerning wider use of capabilities
## Overview
**NOTE** These notes were added to the libcap package in
libcap-1.03. They pre-date file capability support, but fully
anticipate it. They are some thoughts on how to restructure a system
to better leverage capability support. I've updated them to render as
an `.md` formatted file.
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_FOWNER` capability
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 a compromized
daemon where the directory and the files it contains are owned by the
system user. It can be protected to ensure that the daemon is not
running with the `CAP_FOWNER` 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!]
|
