From: Kees Cook <kees.cook@canonical.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dan Rosenberg <drosenberg@vsecurity.com>,
James Morris <jmorris@namei.org>, Joe Perches <joe@perches.com>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Eugene Teo <eugeneteo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] Fix dmesg_restrict build failure with CONFIG_EMBEDDED=y and CONFIG_PRINTK=n
Date: Sat, 13 Nov 2010 19:05:34 -0800 [thread overview]
Message-ID: <20101114030534.GH13854@outflux.net> (raw)
In-Reply-To: <AANLkTi=4AQst9bNXrvwN6sZc2CM9rccYbERYYQkVK99q@mail.gmail.com>
On Sat, Nov 13, 2010 at 12:22:15PM -0800, Linus Torvalds wrote:
> Hmm. No wonder I missed that. The security interface is totally
> idiotic. If the intention is for /proc/kmsg security checks to be done
> at open time, then dammit, that logic should _not_ be inside some
> random security policy.
I think the real problem is that this interface exists as both a syscall
and a /proc file (sysklogd things use the /proc file). Dropping the
from_file means that security policy cannot revalidate the policy
(sometimes it might want to block the read, i.e. passing the open fd to
another process that is not privileged). But since nothing is actually
using from_file yet, I guess it's not a big deal.
And note that I'm not defending any specific part of it; I'm just trying
to point out what not be possible in the future if we drop from_file
like this.
-Kees
--
Kees Cook
Ubuntu Security Team
next prev parent reply other threads:[~2010-11-14 3:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-13 17:26 [PATCH] Fix dmesg_restrict build failure with CONFIG_EMBEDDED=y and CONFIG_PRINTK=n Joe Perches
2010-11-13 17:50 ` Linus Torvalds
2010-11-13 18:25 ` Dan Rosenberg
2010-11-13 20:22 ` Linus Torvalds
2010-11-14 3:05 ` Kees Cook [this message]
2010-11-14 12:35 ` Ingo Molnar
2010-11-13 19:51 ` Joe Perches
2010-11-13 20:01 ` Joe Perches
2010-11-13 20:31 ` Linus Torvalds
2010-11-15 1:16 ` James Morris
2010-11-15 17:04 ` Eric Paris
2010-11-15 17:34 ` Eric Paris
2010-11-15 17:41 ` Linus Torvalds
2010-11-15 17:45 ` Eric Paris
2010-11-15 18:20 ` Linus Torvalds
2010-11-15 22:13 ` James Morris
2010-11-15 22:43 ` Eric Paris
2010-11-15 22:58 ` James Morris
2010-11-15 23:08 ` Eric Paris
2010-11-15 22:16 ` James Morris
2010-11-15 22:36 ` Linus Torvalds
2010-11-15 22:51 ` James Morris
2010-11-14 2:44 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101114030534.GH13854@outflux.net \
--to=kees.cook@canonical.com \
--cc=akpm@linux-foundation.org \
--cc=drosenberg@vsecurity.com \
--cc=eugeneteo@kernel.org \
--cc=jmorris@namei.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.