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: <AANLkTik=mnFDXAyJ53_7FPfD5ETiYY8GjkE5pm0PJSBu@mail.gmail.com>
Date:	Mon, 15 Nov 2010 12:04:39 -0500
From:	Eric Paris <eparis@...isplace.org>
To:	Linus Torvalds <torvalds@...ux-foundation.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>
Subject: Re: [PATCH] Fix dmesg_restrict build failure with CONFIG_EMBEDDED=y
 and CONFIG_PRINTK=n

On Sat, Nov 13, 2010 at 3:31 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> We had this exact problem with the whole "mmap_min_addr" thing. People
> _thought_ of it as generic, but because it was actually tested by the
> security logic, if you ended up enabling SELinux the test actually
> went away entirely (or maybe it was the other way around). So with
> certain security models, the whole thing was bypassed, and the
> security module actually became an _IN_security module.

Your recollection is wrong, although your conclusions of the
ramifications are right.  Either SELinux or capabilities checked
mmap_min_addr, depending on which was 'primary.'  Just as they are
different modules they checked for different things.  Only doing
SELinux checks was stronger for some situations, and only doing
capability checks was stronger in some ways (and the reverse was
obviously true).  Today you get the best of both worlds since we
really have 2 different mmap_min_addr values...

In any case the result of that is that LSMs (ok 'I') need to be more
careful making sure they interact properly with the generic
capabilities hooks.

From: James Morris
> I want to ensure that LSMs which implement security_syslog can't end up
> with a less secure system than the default, regardless of whether they
> call cap_syslog or not.

Which really means that this is total crap.  If you don't call
cap_syslog() you broke it.  That's all there is to it.  Calling the
capability code is always required.  full stop.

I think this patch is broken though.  SELinux and SMACK don't care
about from_file and want to check every time no matter what.  Your
patch breaks that and only will call the LSM on occasion.  It's only
capabilities that likes those semantics.  I think the entire contents
of the cap_syslog hook should be moved up and that hook just dropped
entirely.

I'll code up what I'm thinking in a minute.....

-Eric
--
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/