> Horst von Brand writes:
> > Problem is that jschmoe can take a hex editor to any file she wants,
> > and make it "ALL CAPS" and then SUID it, or just wait for somebody
> > capable to run it. Even if she hasn't got the "set capability"
> > cap. That's why capabilities can not reside in the executable file
> > itself. But if they ar= e
>
> No, because capabilities can only be granted by the sysadmin
> (root). Therefore capability-granting binaries are suid-root and the
> kernel looks at the ELF CAP header.
Actually, I don't think it should work _either_ way; this is why I say a
capability-enhanced binary should be immutable. Before you can write to
the file, you must first un-set the capability flag. Then you modify it,
then you _attempt_ to re-set it. Before the flag gets set the kernel
checks the capelf headers for being legally settable; this includes the
caps, and the actual file owner and setuid bit, since for a
capability-enhanced binary we use the fs representation of owner and
setuid as a flag. The user process must have 'CAP_SETFCAP' raised to be
able to set/unset the cap flag. Works nicely for all uid's, as proper for
a capability-based system.
> Suid-non-root binaries are different: they switch identity. The kernel
> doesn't check the ELF CAP header.
Well, if we agree to store the actual uid and setuid bit in the capelf
headers, then we _can_ have a capability enhanced binary that's also
setuid to another user.
> If some ordinary user wants to create a binary that grants
> capabilities *to others*, he must ask the sysadmin for permission. If
> the sysadmin agrees, he runs a tool to edit/audit the ELF CAP header
> and then chowns to root and chmod u+s.
Eh, but in a capabilities-based system, _any_ user might have the
capability to make a capability-enhanced binary (might have CAP_SETFCAP
raised).
For a good time: read the linux-privs spec and try to make sense of the
formula for the way a new process gets it's capabilities. heh... ugly.
Here's another thought, though. I'm not real crazy about having to store
real uid + suid flag in the headers. Can we just use, say, the 'sticky'
bit on files to flag a binary as capability-enhanced? It would _still_
need to make the file immutable, and setting the bit would _still_ require
CAP_SETFCAP set, plus the other checks; but it'd sure play a hell of a lot
nicer with the VFS wrt actual uid & suid bit...
>
> Regards,
>
> Richard....
>
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
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/