RFC: Capabilities #185
RFC: Capabilities #185
Conversation
…o HEAD Conflicts: configure.in
…nto HEAD Conflicts: configure.in
Conflicts: src/gateway.c
Also protect capabilities with ifdefs
…nto feature-capabilities-2
The new strategy is to use seteuid(), in which case we don't need to care about the capabilities of child processes.
I made some wrong assumptions about execve() in a real-uid 0 context. Only the file capabilities are all enabled, which still requires the caller to have the appropriate capabilities. I will add a comment clarifying the behaviour here.
Turns out I was mistaken about some things - I had accidentally still ran iptables as root. The current code now drops from UID0 to a non-privileged user at startup. There are two occasions where the effective user ID is set back to 0: * in execute() in util.c * in fw_iptables.c with a wrapper around popen
|
Somehow, it's always the non-cyassl build that fails. Looks to be a missing header maybe that gets brought in with cyassl. Try building it without cyassl. |
|
No, the normal build does not respect CFLAGS=-Werror. For some reason. |
|
Re your earlier comment:
This will also need a switch_to_root() call then. INHERITABLE is probably also not needed in the patch above. |
|
Ahhhh, interesting about |
|
Something's weird with the logging. Otherwise, it seems to work. |
| caps = cap_get_proc(); | ||
| debug(LOG_DEBUG, "Dropped caps, now: %s", cap_to_text(caps, NULL)); | ||
| cap_free(caps); | ||
| caps = cap_get_proc(); |
There was a problem hiding this comment.
Missing a cap_free() after this cap_get_proc()
|
I'm done adding line comments throughout your patch ;-) |
"full" build type also builds with --enable-libcap
Also fix build and install of libattr
…nto feature-capabilities-3 Conflicts: src/Makefile.am src/util.c
Configure help alignment
…idog-gateway into feature-capabilities-3
Do not install into lib64/, prefer lib/
…nto feature-capabilities-3 Conflicts: src/conf.c
|
Finally got travis to play nice. |
The comment explained a behaviour which no longer reflected the code
|
Updated so it can be merged. |
I'm submitting a PR as a request for comments/review for capabilities (7) support.
The code drops all privileges except CAP_NET_ADMIN and CAP_NET_RAW and switches the effective user ID to a non-privileged user and group. specified in the config file.
On execvp or popen (e.g. calls to iptables), the code switches the effective UID back to 0. This is needed because there is no way for the child process to inherit these capabilites (1, 2).
This solution is not without problems, as (obviously) an attacker could go back to UID0 and place shell scripts in /etc/cron.d/ or use similar attack vectors. To avoid this problem, a chroot environment would be required. CAP_CHROOT is not permitted anymore, so breaking out would not be a problem.