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]

Date:	Mon, 15 Nov 2010 12:34:42 -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>,
	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 12:04 PM, Eric Paris <eparis@...isplace.org> wrote:
> 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

I'm sure somebody somewhere hates it, but I was thinking something
like the attached.

 include/linux/security.h   |    9 ++++-----
 kernel/printk.c            |   11 ++++++++++-
 security/capability.c      |    5 +++++
 security/commoncap.c       |   21 ---------------------
 security/security.c        |    4 ++--
 security/selinux/hooks.c   |    6 +-----
 security/smack/smack_lsm.c |    8 ++------
 7 files changed, 24 insertions(+), 40 deletions(-)

(Personally I think that most of the hooks in commoncap.c code should
be moved out of security/ altogether and we should completely do away
with our current ghetto inter LSM calls.  But that's just me)

-Eric

View attachment "tmp.patch" of type "text/x-patch" (5870 bytes)