linux-kernel - Re: [PATCH] Fix dmesg_restrict build failure with CONFIG_EMBEDDED=y and CONFIG

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTim5wGt5SZkOJWDMWhS7FSPyEE1xpirpb0bqN9BS@mail.gmail.com>
Date:	Mon, 15 Nov 2010 10:20:56 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Eric Paris <eparis@...isplace.org>
Cc:	Joe Perches <joe@...ches.com>,
	Dan Rosenberg <drosenberg@...curity.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Eugene Teo <eugeneteo@...nel.org>,
	Kees Cook <kees.cook@...onical.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	James Morris <jmorris@...ei.org>,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] Fix dmesg_restrict build failure with CONFIG_EMBEDDED=y
 and CONFIG_PRINTK=n

On Mon, Nov 15, 2010 at 9:45 AM, Eric Paris <eparis@...isplace.org> wrote:
>
> That is the rule for ALL of the hooks in commoncap.c.  The one time I
> tried to do something else *cough*mmap_min_addr*cough* I screwed it
> up.  I'll put a note in my todo list about looking into lifting all of
> commoncap.c into the callers.

Into "security/security.c" itself? That would work, except it doesn't
work exactly in a situation like this where the whole interface was
polluted by the commoncap version simply having fundamentally
different semantics (ie the whole "no security check at read time,
only at open time"). Passing the whole "from_file" thing around was
just ugly.

And while passing the commoncap cases down into the callers of the
"security_xyz()" interface itself makes sense in this case, I don't
think it makes sense in general. With 'security_syslog()' there really
was just one very specific call-site. Other security wrappers have
many more (eg "security_vm_enough_memory()") call sites, and moving
the cap_xyz() code to those callsites would be totally wrong
duplication.

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