Messages in this thread | | | From | (Peter Benie) | Subject | Re: Capabilities | Date | Thu, 10 Feb 2000 01:26:17 +0000 |
| |
Chris Evans writes ("Re: Capabilities"): > On Wed, 9 Feb 2000, Peter Benie wrote: > > > > For this change to be useful, xntpd needs to run as a uid other than > > 0, otherwise it can overwrite files owned by root, regardless of what > > capabilities it has. This is no big deal - we just have to call setuid > > to change uid. > > > > Here's the problem - if you have any programs that don't understand > > capabities, you have to run without SECURE_NO_SETUID_FIXUP or else > > they won't throw away privilege correctly. In that mode, changing to a > > If a process has its capabilities changed via sys_capset(), it is marked > as capability aware. When a "capability aware" process does setuid(0 -> > !=0), capabilities are not cleared. The "capability aware" flag is cleared > on exec(). > > Let me know if this solution meets your needs
Yes it does - it allows me to write the obvious code instead of the gross hack from my original article. Having said that, it is unclean in that the side-effect of sys_capset is extremely non-obvious; I'd probably be happier making the state change explicit with prctl().
> I've tested the solution. Im very glad to hear you are de-privving > xntpd. I'd like to see that change in distributions ASAP! > People de-privving bind (thank God) have also hit this issue
Does bind really benefit from this treatment? It already has a -u, -g and -t options to change the user, group, and chroot point respectively. Using -u does stop you changing which port the server is bound to without restarting the program but that's hardly a great problem. Capabilities don't solve the inability to change which port is bound since cap_net_bind_service is equivalent to root on most machines.
> Awaiting your reply then I will stop delaying getting this important fix > into the kenrel.
There are another couple of issues regarding capabilities which concern me.
1) Permitted capability set for setuid programs
I want setuid root programs not to have all capabilites. cap_bound is not the answer since I still want some programs that are started from the system initialisation scripts to run with all capabilities.
2) Inherited capability set for setuid programs
It is possible to run a non-capability-aware setuid-root program from an environment that has cap_setuid-i. This prevents the program from using setuid() to demote privilege back to a non-zero uid (unless that uid was the real, effective or saved uid). This is a security risk since the program might retain the ability to write to any file on the system owned by root. When doing setuid root emulation, the inherited rights mask should not be honoured.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |