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]

Date:	Wed, 24 Apr 2013 17:15:36 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	LSM <linux-security-module@...r.kernel.org>,
	LKLM <linux-kernel@...r.kernel.org>,
	SE Linux <selinux@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	John Johansen <john.johansen@...onical.com>,
	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 01:22:20 PM Casey Schaufler wrote:
> On 4/24/2013 11:57 AM, Paul Moore wrote:
> > I know we had a good discussion about this a while back and I just wanted
> > to hear from you about this current patchset; how does the labeled
> > networking LSM assignment work?  Is it first-come-first-served based on
> > the 'security=' setting?
> 
> It's explicitly set in security/Kconfig. The problem with
> first-come-first-serve is that the LSMs don't actually register
> in the order specified, either at build time or boot time.
> Further, until the init phase is complete, you don't know which
> LSMs are actually going to register. That, and I promised Tetsuo
> I wouldn't go out of my way to prevent late module loading in
> the future.
> 
> I could do order checking on module registration and take
> the networking component away from an LSM that registered
> earlier, but with a larger order number I suppose.

Hmmm.  How difficult would it be to enforce the order during LSM registration?  
As discussed previously, I'm not a big fan of assigning the network controls 
at compile time when the LSMs can be toggled at boot time.

The real solution is to just get the netdev folks to accept a security blob in 
the sk_buff so we can fix this (and many other problems) once and for all.  I 
still haven't given up on this effort but I think it would be silly to hold up 
the stacking effort for the sk_buff security blob.

> The default configuration gives xfrm and secmark to SELinux
> and NetLabel to Smack. If Smack is not included NetLabel goes
> to SELinux. When LSMs using any of these facilities are added
> in the future we'll have to negotiate the defaults.

The defaults are always going to be wrong for someone.

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

> It would be possible to have a boot time specification for
> the networking components if you think it's important. I do
> worry about making it excessively complicated. I'd be much more
> concerned if more LSMs used the networking components.

I think the "excessively complicated" boat has already sailed :)

I'm still in favor of assigning the network hooks to the LSM at boot based on 
the "security=" configuration.

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