linux-kernel - Re: [AppArmor 00/44] AppArmor security module overview

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:	Mon, 02 Jul 2007 10:45:09 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	John Johansen <jjohansen@...e.de>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 00/44] AppArmor security module overview

Adrian Bunk <bunk@...sta.de> writes:

> On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
>> On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <jjohansen@...e.de> wrote:
>> 
>> > > 
>> > > so...  where do we stand with this?  Fundamental, irreconcilable
>> > > differences over the use of pathname-based security?
>> > > 
>> > There certainly seems to be some differences of opinion over the use
>> > of pathname-based-security.
>> 
>> I was refreshed to have not been cc'ed on a lkml thread for once.  I guess
>> it couldn't last.
>> 
>> Do you agree with the "irreconcilable" part?  I think I do.
>> 
>> I suspect that we're at the stage of having to decide between
>> 
>> a) set aside the technical issues and grudgingly merge this stuff as a
>>    service to Suse and to their users (both of which entities are very
>>    important to us) and leave it all as an object lesson in
>>    how-not-to-develop-kernel-features.
>> 
>>    Minimisation of the impact on the rest of the kernel is of course
>>    very important here.
>> 
>> versus
>> 
>> b) leave it out and require that Suse wear the permanent cost and
>>    quality impact of maintaining it out-of-tree.  It will still be an
>>    object lesson in how-not-to-develop-kernel-features.
>>...
>
> versus
>
> c) if [1] AppArmor is considered to be something that wouldn't 
>    be merged if it wasn't already widely deployed by Suse: leave it out, 
>    work on an ideal solution [2], and let Suse wear the one-time cost
>    of migrating their users to the ideal solution
>
> One important point is that if AppArmor gets merged there will be much 
> more distribution support for it, and many people on !Suse will start 
> using it.
>
> I'm not claiming to understand the technical details, but from both 
> slightly reading over the previous discussions and the "What are the 
> advantages of AppArmor over SELinux?" section in the AppArmor FAQ [3] my 
> impression is that a main advantage of AppArmor are more user friendly 
> userspace tools. Therefore, if [1] AppArmor is considered technically 
> inferior to SELinux, it might still become more popular than SELinux 
> simply because it's easier to use - and although it's technically 
> inferior.

A couple of random thoughts to mix up this discussion.

>From what I have been able to observer the LSM is roughly firewalls
rules for in box operations.  All it can do is increase the chances
you will get -EPERM.

Not being able to take path names into consideration is a current
deficiency of the LSM.

Being exported to modules is another deficiency of the current LSM
as it seems no serious user of the LSM can exist simply as a kernel
module.

Not being able to mix code from different projects is also a very
serious limitation of the LSM.  Currently I don't think we can
build a kernel that supports selinux and any other LSM at the same
time.  Which horribly limits what we can do with the LSM.

So it seems clear that if we are aiming at an ideal solution.  We
first need to enhance the LSM.  Then merge in the AppArmor
functionality.  Doing it all in one patch series looks to overwhelming
for a decent code review.

That said is anyone interested in making the LSM more like iptables
with a generic table based rules structure?  That way we could fix
the one true LSM problem and concentrate on simpler pieces that give
specific bits of interesting functionality.  Or at the very least
be able to compile in multiple different bits of functionality into
the kernel simultaneously.

I'm really not familiar with the security issues the LSM addresses
but I do know, it encourages huge incompatible mega solutions, and
it tends to break when I fix real security problems in the kernel.
So at this point I am convinced that the LSM is deficient, has very
limited usability, and seems to be a very fragile firewall structure
to me.

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