Re: Capabilities

From: tytso@valinux.com
Date: Fri Feb 11 2000 - 08:17:40 EST


   Date: Fri, 11 Feb 2000 13:08:39 +0000 (GMT)
   From: Chris Evans <chris@ferret.lmh.ox.ac.uk>

   On Thu, 10 Feb 2000 willy@thepuffingroup.com wrote:

> it though. One thing the capabilities people could help us with is by
> saying whether they are willing to restrict themselves to 32 capabilities
> for ever or whether they think they will need more (and if so, how many?
> Is there a realistic upper bound?).

   In 2.3 I believe we are currently using 28/32.

   We are just starting to see some real-world usage of capabilities, in the
   form of restricting the capabilities certain daemons are running with. As
   capabilities are used more, a few ommissions will be detected and I think
   we will overrun 32 bits.

   Since filesystem data structures are, shall we say, tricky to change after
   the fact, PLEASE budget 64 bits. 64 bits should suffice relatively long
   term. Do people concur?

Well, there's a trade off here. If you could have 32 bits basically
almost right away, and more would take longer, which would you choose?
Also, keep in mind that more bits is not necessarily good. There is a
*huge* complexity cost in maintaining capabilities. People have enough
trouble keeping track of the 12 bits of permissions on a per file
basis. This adds one or two orders of magnitude of more bits for every
executable.

However, my knowledge of human nature being what it is, I agree with you
that unless very strong measures are taken to control the virtual
explosion of new capabilities people will want to add, we will need more
bits. So I'd suggest either putting a hard limit on 32 bits, or
budgeting 128 or 256 bits, since bits are relatively cheap once you
exceed 32.

People who are interested developing capability source should seriously
think about ways to control the complexity, though. If the user-mode
management tools aren't good enough, capabilities will be a diaster, and
their use could actualy decrease the overall security on a system.

                                                        - Ted

-
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:20 EST