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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:16 EST