linux-kernel - Re: [PATCH v13 0/9] LSM: Multiple concurrent LSMs

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: <47138397.PP25Tg7m1s@sifl>
Date:	Thu, 25 Apr 2013 11:01:50 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	John Johansen <john.johansen@...onical.com>,
	LSM <linux-security-module@...r.kernel.org>,
	LKLM <linux-kernel@...r.kernel.org>,
	SE Linux <selinux@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	Eric Paris <eparis@...hat.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v13 0/9] LSM: Multiple concurrent LSMs

On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
> On 4/24/2013 4:00 PM, John Johansen wrote:
> > On 04/24/2013 02:15 PM, Paul Moore wrote:
> >> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:

...

> >>> An interesting aside that may be relevant is that the error
> >>> condition behavior makes it advisable to have the LSM you care
> >>> about most go last. If the networking components were strictly
> >>> FCFS you might have to chose an ordering you might not want for
> >>> other reasons.
> >> 
> >> Well, maybe not ... I think.  If we take a FCFS approach to the network
> >> controls then only one LSM is really ever going to throw an error on the
> >> network hooks, yes?
> 
> You set up the order you want to get the networking handled
> correctly and you could get filesystem hooks in the wrong order.
> Not that that really ought to be a problem, but there are wonky
> admin tools out there.

I don't quite follow; can you be a bit more explicit about getting the 
filesystem hooks in the wrong order?

> >> I'm still in favor of assigning the network hooks to the LSM at boot
> >> based on the "security=" configuration.
> > 
> > yeah dealing with selection at boot time is going to be needed
> > at some point, whether its now or later ...
> 
> I'll have a go at it then. What that would mean is that:
> 
> 	security=smack,selinux
> 
> gives Smack NetLabel and SELinux xfrm and secmark while
> 
> 	security=selinux,smack
> 
> gives SELinux all three.

That seems reasonable, it also keeps the door open for adding a specific 
network hook ordering option, e.g. "security_net=", at a later date if 
necessary.

> I would still like it to be possible to explicitly configure the allocation
> at build time.

I suppose I have no object to that, I would just place my vote to have the 
dynamic FCFS (or LCFS if that makes more sense) assignment be the Kconfig 
default.

-- 
paul moore
www.paul-moore.com

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