Re: capabilities patch (v 0.1)

[David Madore <david.madore@ens.fr>]

On Tue, Aug 09, 2005 at 05:37:56AM +0000, Chris Wright wrote:
> * David Madore (david.madore@ens.fr) wrote:
> > * Second, a much more extensive change, the patch introduces a third
> > set of capabilities for every process, the "bounding" set.  Normally
> 
> this is not a good idea.  don't add more sets.

Could you elaborate?  Why is adding sets bad?  From what I read of the
June 2000 discussions on the linux-privs-discuss mailing-list (<URL:
http://sourceforge.net/mailarchive/forum.php?forum_id=25120&max_rows=25&style=flat&viewmonth=200006
 >), a rather large consensus had formed around the idea that some
kind of bounding set was a useful idea (as a matter of fact, the
sendmail problem came essentially from the fact that some people
wanted an inheritable set and other people wanted a bounding set, and
the code was some mixture of the two); and it had been argued
convincincly that it could be made POSIX compliant if that is the
issue.  Plus, Solaris privileges also come in four sets.

If it's compatibility you're worried about, it seems to me that the
user interface can be made so that it will still work with the old
libcap and merely ignore the bounding set.  So full binary
compatibility will be achieved, at least on the user level.

Finally, if it's a matter of kernel policy, I seem to understand that
my patch has a snowball's chance in hell of ever being accepted in the
mainstream kernel (I mean, it's not as though this were new: patches
to make capabilities work have been available ever since the sendmail
exploit, and in five years they haven't ever been accepted, so I
suppose there's a reason to this), so adding a fourth set of
capabilities of my own initiative isn't going to change a thing there.

So what's the problem?

>						 if you really want to
> work on this i'll give you all the patches that have been done thus far,
> plus a set of tests that look at all the execve, ptrace, setuid type of
> corner cases.

Yes, I'm very interested in the test suite.

-- 
     David A. Madore
    (david.madore@ens.fr,
     http://www.madore.org/~david/ )