On 15 Apr 1999, Andreas Barth wrote:
> On 15 Apr 1999 05:13:09 +0200, David L. Parsley (lkml account) <kparse@salem.k12.va.us> wrote:
> > But let me use the named(8) example again, because I've thought it over
> > again and find that my original thinking was wrong. (why am I picking on
> > named(8) you ask? because that's how my box was rooted. that's why I'm
> > on a holy mission to get capabilities implemented)
>
> But you don't need capabilities for named at all. Named could be
> secured if there's a port-device-map which describes who (uid)
> may use which port. Named would get a port, mail another and so
> on.
>
> There was a patch for this around (called sockfs).
IMHO, this adds unneeded complexity; besides, my solution allows the
attacker to listen on _no_ ports, where sockfs would presumably allow
listening on 53.
> (But capabilities are a good thing and should be implemented. Only
> named doesn't need it.)
named(8) just happens to be my favorite example, but others apply as well;
at this point, I think the question is: do we implement capabilities as
they were designed to be implemented (stickybit/immutable solution), or do
we break the semantics of capabilities to work around problems in the
solution based on setuid-root?
I reallize setuid-root has better compatibility over remote fs's, but IMHO
correctness of implementation far outweighs this consideration; especially
in light of the fact that stickybit/immutable has much _better_
compatibility than caps in fs metadata, which would wholesale break many
utilities and over all remote filesystems. (caps in fs metadata seems to
be an eventual goal)
cheers,
David
- --
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/