[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTin60NFzgx+oa3Y9c9QK_rYjAg-qwDHrr287f8Aj@mail.gmail.com>
Date: Sat, 18 Dec 2010 16:10:49 -0500
From: Eric Paris <eparis@...isplace.org>
To: Dan Rosenberg <drosenberg@...curity.com>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
linux-security-module@...r.kernel.org, jmorris@...ei.org,
eric.dumazet@...il.com, tgraf@...radead.org, eugeneteo@...nel.org,
kees.cook@...onical.com, mingo@...e.hu, davem@...emloft.net,
a.p.zijlstra@...llo.nl, akpm@...ux-foundation.org
Subject: Re: [PATCH v3] kptr_restrict for hiding kernel pointers
On Sat, Dec 18, 2010 at 4:07 PM, Eric Paris <eparis@...isplace.org> wrote:
> On Sat, Dec 18, 2010 at 12:20 PM, Dan Rosenberg
> <drosenberg@...curity.com> wrote:
>
>> @@ -1035,6 +1038,26 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
>> return buf + vsnprintf(buf, end - buf,
>> ((struct va_format *)ptr)->fmt,
>> *(((struct va_format *)ptr)->va));
>> + case 'K':
>> + /*
>> + * %pK cannot be used in IRQ context because it tests
>> + * CAP_SYSLOG.
>> + */
>> + if (in_irq() || in_serving_softirq() || in_nmi())
>> + WARN_ONCE(1, "%%pK used in interrupt context.\n");
>> +
>> + if (!kptr_restrict)
>> + break; /* %pK does not obscure pointers */
>> +
>> + if ((kptr_restrict != 2) && capable(CAP_SYSLOG))
>> + break; /* privileged apps expose pointers,
>> + unless kptr_restrict is 2 */
>
> I would suggest has_capability_noaudit() since a failure here is not a
> security policy violation it is just a code path choice.
>
> I was confused also by the comment about CAP_SYSLOG and IRQ context.
> You can check CAP_SYSLOG in IRQ context, it's just that the result is
> not going to have any relation to the work being done. This function
> in general doesn't make sense in that context and I don't think saying
> that has anything to do with CAP_SYSLOG makes that clear.... Unless
> I'm misunderstanding...
Just went back and reread akpm's comments on -v2. I guess we see it
the same way, I just thought this comment on first glance indicated
that capable() wasn't IRQ safe (it is) not that it just was
meaningless... I don't think rewriting the comment is necessary.
Sorry for that half of the message....
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists