lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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