On Thu, 10 Feb 2000, Peter Benie wrote:
> > 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().
> in that the side-effect of sys_capset is extremely non-obvious; I'd
> probably be happier making the state change explicit with prctl().
FW(L)IW, so would I.
> Capabilities don't solve the inability to change which port is bound
> since cap_net_bind_service is equivalent to root on most machines.
Please explain? If bind has only CNBS and runs as user "named",
then there is no root equivalence that I can see.
> 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.
Mmm.. I'd like that too.
> 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.
The whole lot, or merely CAP_SETUID?
I see no reason that these two shouldn't be sysctls. Want
a patch?
Matthew.
-
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:17 EST