grsecurity forums

i have a kernel from ubuntu 10.04 patched with grsecurity patch 2.2.1.
i have enabled CONFIG_GRKERNSEC_CHROOT_CAPS option (and also appropriate sysctl option).
but when i running my daemon (if you want i can provide a source code) that needs cap_sys_time,cap_net_bind_service capabilities.
the work flow is the following:
[*] drop all capabilties to cap_sys_time,cap_net_bind_service,cap_sys_chroot,cap_setuid,cap_setgid
[*] seteuid (1000:1000)
[*] drop all capabilties to cap_sys_time,cap_net_bind_service,cap_sys_chroot
[*] chroot to some dir
[*] daemonize
[*] make chdir("/")
[*] drop all capabilties to final needed set: cap_sys_time,cap_net_bind_service
it succeeds to do everything including chroot but fails to drop allcapabilties to cap_sys_time,cap_net_bind_service.

however, the help of says:

the capabilities on all root processes within a
chroot jail will be lowered to stop module insertion, raw i/o,
system and net admin tasks, rebooting the system, modifying immutable
files, modifying IPC owned by another, and changing the system time.

i'm a little bit confused because my daemon runs in chroot with non-0 uid and gid...

however when disabling sysctl option

Code: Select all

sysctl -w kernel.grsecurity.chroot_caps=0

everything goes fine.
am i missing something?

Hi sir,

The mention of root processes in the configuration help is a simplification. On chroot, the capabilities are lowered regardless of uid, so if a process performs the chroot with those capabilities raised -- they will be removed even if the process has a non-zero uid.

I plan to rewrite this feature so that the denied capability usage can be tracked back to the option and will include documentation changes in the rewrite.

Thanks,
-Brad

The mention of root processes in the configuration help is a simplification. On chroot, the capabilities are lowered regardless of uid, so if a process performs the chroot with those capabilities raised -- they will be removed even if the process has a non-zero uid.

so i do not understand the logic of CONFIG_GRKERNSEC_CHROOT_CAPS:
why to drop capabilities after the chroot(2) is called , because :
[*] before process makes the chroot(2) call, it should drop all unneeded capabilities (except sys_chroot for sure).
[*] (in most cases) some privileged operations should be done in a chroot . like binding to port<1024 (80,53,etc),configuring datetime, etc.

if you are droppping all capabilities after chroot call the jailing process is useless, since you cannot bind.
for example the way i'd hardening DNS server is:
[*] setuid,settgid to non-0
[*] chroot
[*] bind to port 53 with the only capability raised (cap_net_bind_service)

but i agree that the gap is the legacy sofware that do not make use of capabilities.in that case CONFIG_GRKERNSEC_CHROOT_CAPS will just break it and should be turned off in any case.