linux-kernel - Re: [PATCH] LSM: ModPin LSM for module loading restrictions

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: <alpine.LRH.2.02.1310231047180.7063@tundra.namei.org>
Date:	Wed, 23 Oct 2013 11:02:36 +1100 (EST)
From:	James Morris <jmorris@...ei.org>
To:	Casey Schaufler <casey@...aufler-ca.com>
cc:	Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org,
	James Morris <james.l.morris@...cle.com>,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH] LSM: ModPin LSM for module loading restrictions

On Thu, 17 Oct 2013, Casey Schaufler wrote:

> On 10/17/2013 1:02 AM, James Morris wrote:
> > This seems like a regression in terms of separating mechanism and policy.  
> >
> > We have several access control systems available (SELinux, at least) which 
> > can implement this functionality with existing mechanisms using dynamic 
> > policy.
> 
> They said the same thing about Smack.
> 

Nope.  Smack separates mechanism and policy.  The argument then was 
whether we need more than one such enhanced access control system.

The issue now is that we do have several of them (SELinux, Smack, 
AppArmor) which are policy-flexible, whether to regress back to adding 
hard-coded security policies into the kernel.

> The problem there is that you have to buy into the entirety of
> SELinux to implement a small bit of behavior. You have to write
> a policy that takes every aspect of system behavior into account
> when all you care about is loading restrictions on modules.

You always need to consider the behavior of the system as a whole when 
designing security policies.

It's a major step backwards to hard-code a series of ad-hoc policies in 
the kernel.  You still need to compose them somehow, and reason about the 
security of the system as a whole.

> The rationale is that lots of people doing little things is
> likely to get us relevant security in a reasonable amount of time.
> The existing LSMs reflect 20th century technologies and use cases.
> They are fine for multi-user timesharing systems. We need to move
> forward to support networked gaming, phones, tablets and toasters.

You keep making these grand assertions but never provide any detail, or 
any kind of evidence to back them up.  Yet there are many, many examples 
of how the current LSMs meet all of these needs in the 21st century, such 
as Smack being adopted for Tizen, digital television etc.:

http://en.wikipedia.org/wiki/Smack

- James
-- 
James Morris
<jmorris@...ei.org>
--
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/