On Thu, 10 Feb 2000, Matthew Kirkwood wrote:
> > 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.
You'll get that when the filesystem support for capabilities goes in.
Alternatively, tighten up the bounding set as part of your system
initialisation scripts.
> > 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?
It feels like functionality for the sake of it. The capabilities stuff
already has a few bells and whistles, not to mention complexity. And very
few people are using it. I'd be happier to just fix the remaining serious
capabilities bug identified, and then let people _use_ the stuff in
2.4. Hopefully distro's themselves will ship lower-privileged daemons.
Once we've got some proper, extensive _real world_ use of capabilities,
we'll be in a better situation to evaluate what tweaks/additions are
required. Quite a lot of capabilities complaints boil down to
"theoretically, this could be an issue" rather than "I've been using
capabilities to do X, and came across this issue"
Cheers
Chris
-
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:18 EST