I've tried to use capabilities to run xntpd without excessive privilege.
Not surprisingly, the only capabiity xntpd requires is cap_sys_time.
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
non-zero uid clears the effective and permitted capability sets. This
is no good since you now have insufficient privilege to do what you
want, so you employ the following horrible hack. (Have your Unix
barf-bag ready...)
fork
[Parent] [Child]
setgroups block, waiting for parent
setgid
setuid
unblock child
wait for child catsetp(getppid, capabilities)
exit
The child is still running as root with all capabities, so it can hand
over cap_sys_time to the parent. The parent will then have a non-zero
uid and a non-empty capability set.
This must have worked once since sucap relies on a similar trick, but
it doesn't work now because of how init is started.
#define CAP_INIT_EFF_SET to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
#define CAP_INIT_INH_SET to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
This results in all children of init running with cap_setpcap-i, so
the child process cannot hand over cap_sys_time to the parent.
There are severval solutions to this problem:
1) Run init with all=eip.
I can't see any reason to do otherwise, but the choice not to looks
extremely deliberate. Am I missing something obvious here?
2) Add an extra system call that changes uid (if CAP_SETUID is set)
just like setuid(), but doesn't change capability sets.
3) Make SECURE_NO_SETUID_FIXUP a per-process attribute rather than
per-system.
Comments please?
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:15 EST