Messages in this thread | | | From | (Peter Benie) | Subject | Capabilities | Date | Wed, 09 Feb 2000 12:26:07 +0000 |
| |
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/
| |