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: <CAGXu5jK4wM2oD89HQ4Yx+YG9VNQm0Pnyx1bGt3irkw7NVkQHYA@mail.gmail.com>
Date:	Thu, 17 Oct 2013 14:09:56 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	James Morris <jmorris@...ei.org>,
	LKML <linux-kernel@...r.kernel.org>,
	James Morris <james.l.morris@...cle.com>,
	linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] LSM: ModPin LSM for module loading restrictions

On Thu, Oct 17, 2013 at 10:26 AM, Casey Schaufler
<casey@...aufler-ca.com> 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.
>
> 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.
>
> If you want all of SELinux you still have to define your problem
> in a subject/object model. That may be possible, but in this
> case at least it certainly ain't obvious.
>
>> I'm concerned about the long term architectural impact of a proliferation
>> of arbitrary hard-coded security policies in the kernel.  I don't
>> understand the push in this direction, frankly.
>
> 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.

I, obviously, agree with with this. At least with Chrome OS, we've
been taking an architectural approach to security. Our trust model is
based on very different ways of doing things, and this results in
needing to trust things that are not part of the traditional
subject/object model, IMO. We trust the contents of our root
filesystem, so there's no need to do things like module signing, etc.
In many ways, IMA follows similar approaches but at a different layer
(i.e. we use dm-verity).

Chrome OS has been using this LSM for about a year now. It provides
demonstrably improved security since it draws a bright line between
uid-0 and ring-0 on systems that have a verified boot path but use
kernel modules.

-Kees

-- 
Kees Cook
Chrome OS Security
--
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/