John Johansen john.johansen at canonical.com
Wed Aug 1 19:47:58 UTC 2012

On 07/26/2012 05:34 AM, Tim Gardner wrote:
> On 07/20/2012 02:57 PM, Kees Cook wrote:
>> This adds a few bytes of overhead to each credential and adds a tiny
>> amount of CPU overhead when changing credentials. It can catch some
>> types of credential manipulation attacks, so turn it on.
>> Signed-off-by: Kees Cook <kees at ubuntu.com>
>> ---
> Kees - I'm curious how a credential attack might be attempted? If a successful credential attack is possible, then this option provides an excellent DOS since AFAICT every credential check failure ultimately ends up in a BUG() statement. I think DEBUG_CREDENTIALS was designed as a coding aid to detect reference counting and RCU mistakes, not as a protection method against attacks.
There are a couple of different vectors to attack creds but I can't see how
the current DEBUG_CREDENTIALS would stop the attacks, though it would
possibly make the overwrite attack harder.

1. is a use after free attack. Basically there is an uncounted reference
   still in use or an extra put ..

   You exploit it by getting an unprivileged task/object to "free" the
   cred and getting a privileged task to allocate the freed cred,
   reinitializing it into a privileged cred.

   However the debug code will only help in the race window, if the
   cred is referenced while it is freed. Once it has been reinitialized
   the cred looks good and the error won't be caught.

2. some kind of memory overwrite attack, where the attacker has some
   limited ability to overwrite the cred. The debug code won't catch
   most over writes, unless it results in a wrong magic value or
   the task ref count > than the cred ref count

At the moment I am leaning towards saying No to turning this on for our
default kernels, because while the cost is small (noise with the limited
testing I have done). I don't see it actually stopping most actual

I will poke some more and hopefully kees can slap some sense into me,
and make me see what I am missing.

More information about the kernel-team mailing list