Member Avatar for leghorn

Hi

how can we compile linux kernel with CONFIG_SECURITY_CAPABILITIES=y ??

Also what does this flag do ??

Trying to run ntpd in non-root mode

~cheers

  • 2 Contributors
  • 3 Replies
  • 235 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by rubberman

Dani AI

Generated

Quick, practical summary for (2.6.24) and follow-up to ’s notes.

Linux “capabilities” split root powers into named bits. On kernels around 2.6.24 you have a kernel-side capability framework plus the file-backed POSIX capabilities feature (the security.capability xattr). Enabling the kernel options gives the kernel the machinery to apply capabilities on exec and to let userspace set file capabilities. (cateee.net)

Why ntpd wants root: setting the system clock (settimeofday/adjtimex) requires CAP_SYS_TIME; binding the NTP port (UDP/123) requires CAP_NET_BIND_SERVICE. Modern ntpd uses prctl(PR_SET_KEEPCAPS) then drops to an unprivileged user while keeping only the specific capabilities it needs (so it can run without staying full root). That makes a non-root run possible, but only if the kernel and userspace capability support are present. (man7.org)

How to make it work (practical steps):

  • Build a kernel with the capability options enabled (copy your current config, run make menuconfig → Security options → enable Default Linux Capabilities and File POSIX Capabilities, then make -j$(nproc) && sudo make modules_install install and reboot). (kernelnewbies.org)

  • Once the running kernel supports file caps, give ntpd just the caps it needs (run as root):

    setcap 'cap_sys_time,cap_net_bind_service=ep' /usr/sbin/ntpd
getcap /usr/sbin/ntpd

    Verify with getcap / capsh and that ntpd actually drops privileges correctly. (manpages.debian.org)

Important cautions and troubleshooting

  • Filesystem must support extended attributes; rewriting the binary clears file caps. Writing file caps requires root (CAP_SETFCAP). If systemd starts ntpd, the unit’s CapabilityBoundingSet/AmbientCapabilities can override file caps — prefer configuring the unit if you use systemd. Limit who can execute the ntpd binary (strict ownership/mode) because giving CAP_SYS_TIME is powerful. Check your active kernel config in /boot/config-$(uname -r) or /proc/config.gz if available. (man7.org)

If anything fails, post the exact kernel .config (or output of zcat /proc/config.gz) and getcap /usr/sbin/ntpd so it’s possible to point at the specific missing piece.

Recommended Answers

All 3 Replies

Member Avatar for rubberman

The ntpd daemon needs to be able to set the hardware clock, and it can't do that without root permissions.

What kernel are you running? I'm looking at my RHEL 6.2 system (latest 2.6.32 kernel) and there is no such configuration setting. What I have similar to that are as follows:

# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_SECURITY_FILE_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
Edited by rubberman
Member Avatar for leghorn 
I'm using 2.6.24 (mandatory .. cant change it )

there sure is ths option of CONFIG_SECURITY_CAPABILITIES =y

there has to be a way that ntpd works in non-root mode.

I'm sure there is s concept called linux capabilities. We can drop them

and alter the omnipotence of the superuser.

I just am having a hard time looking things up the web

~cheers
Member Avatar for rubberman

2.6.24 eh? Must be Debian Etch. I'll have to dig up my kernel sources for that - they are on a drive currently off-line, so it will probably be next week before I can get back to you about that (going away for the weekend). I use it for an ARM development board I have. In any case, doing that can be very dangerous - caveat programmer! If this is (as is likely) an embedded system and you lock down remote access to it properly, it may not matter, but that is just an observation.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.