Messages in this thread | | | Date | Thu, 15 Apr 1999 10:06:52 -0400 (EDT) | From | "David L. Parsley (lkml account)" <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
Hi Andi,
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/
| |