Re: [ linus-git ] prctl(PR_SET_KEEPCAPS, ...) is broken for someconfigs, e.g. CONFIG_SECURITY_SELINUX

[Serge E. Hallyn]

Quoting Andrew Morton (akpm@xxxxxxxxxxxxxxxxxxxx):
> On Sun, 08 Jun 2008 15:34:44 -0700 Andrew Morgan <morgan@xxxxxxxxxx> wrote:
> 
> > | On Sun, 08 Jun 2008 08:10:26 -0700 Andrew Morgan <morgan@xxxxxxxxxx>
> > wrote:
> > |
> > |> Nacked-by: Andrew G. Morgan <morgan@xxxxxxxxxx>
> > |>
> > |> In a configuration in which you are not using capabilities, what is the
> > |> "keep capabilities" operation supposed to do? Lie to you?
> > |>
> > |> http://bugzilla.kernel.org/show_bug.cgi?id=10748
> > |
> > | I totally agree with comment 11 there. Quite a number of people have
> > already
> > | hit this and more surely will.  How can we help them (and hence us)?
> >
> > What do people think about comment #8 from Stephen Smalley?:
> > 
> > The dummy module is generally in the untenable position of having to lie
> > to userspace or break the existing capability-related system call
> > interface.  It should just go away, and make capability the default
> > module (w/ stubs for the rest of the LSM hooks as with dummy).  Then
> > CONFIG_SECURITY=n will yield the same result as CONFIG_SECURITY=y w/o
> > any further options.
> 
> (removed pgp crap, undid top-posting.  Your emails are very hard to reply to)
> 
> It's a fine comment, but I am not knowledgeable enough in this area to
> say whether it's a desirable thing to do for 2.6.26.
> 
> I fear that nothing will happen, and we'll end up wasting a lot of
> peoples' time sending hey-why-did-my-dhcp-break reports.

If we decide to get rid of dummy long-term, then it's far less
distasteful to have it lie and claim the keepcaps worked in the
meantime.

So for 2.6.26 we could have dummy lie, then plan to make capabilities
the default for 2.6.27?

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/