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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Oct 2013 18:03:24 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	James Morris <jmorris@...ei.org>
CC:	Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org,
	James Morris <james.l.morris@...cle.com>,
	linux-security-module@...r.kernel.org,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH] LSM: ModPin LSM for module loading restrictions

On 10/22/2013 5:02 PM, James Morris wrote:
> 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.

This is right thinking. It's just not common thinking.

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

It's not like we're talking about throwing out the legacy monolithic LSMs.
And let us not forget that Fedora is using SELinux and Yama. There's a
perception of value in independent security mechanisms used in combination.

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

Cool! Most people use other, less complimentary adjectives!

> assertions but never provide any detail, or 
> any kind of evidence to back them up.

There are simple reasons for that. Between Tizen and the stacking patch
the work on a real Application+Service+Resource security model and the
implementation thereof has gotten insufficient attention. I have been
emphasizing work on enabling technology over work on what needs to be
enabled. Kees' approach to security development on CromeOS is the example
I'll hold up for the wave of the future.

> 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.:

Smack in Tizen is an example of old school distribution packaging.
Tizen is very old school in its approach. It's working out pretty
well, but Tizen is hardly a major advance in the world of OS security.

If you look at Android, their (re/miss/ab)use of the UID mechanism and
reliance on the binder to wedge an application based security policy
on top of existing mechanisms it should be pretty obvious that they
would have been better suited with new security features than with
retrofitting to existing technology.

SEAndroid is taking a refreshing approach by putting the access controls
in the middleware and by doing so enabling an appropriate implementation
on the flask architecture. I would not say that SEAndroid qualifies as an
example of adopting an LSM.

> http://en.wikipedia.org/wiki/Smack
>
>
>
> - James

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