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:	Thu, 28 Jun 2007 14:48:06 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Tilman Schmidt <tilman@...p.cc>
Cc:	David Miller <davem@...emloft.net>, crispin@...ell.com,
	seanlkml@...patico.ca, akpm@...ux-foundation.org,
	jjohansen@...e.de, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: [AppArmor 00/44] AppArmor security module overview

On Thu, Jun 28, 2007 at 01:27:12PM +0200, Tilman Schmidt wrote:
> David Miller schrieb:
> > What you get by the code going into the upstream kernel tree is that
> > it a) adds some pseudo legitimacy to AppArmour (which I don't
> > personally think is warranted) and b) gets the work of keeping
> > apparmour working with upstream largely off of your back and in the
> > hands of the upstream community.
> > 
> > Neither of those are reasons why something should go into the tree.
> 
> I beg to differ. b) is *the* reason cited again and again on LKML
> for submitting code for inclusion in the tree. Whenever anyone
> posts anything which is remotely related to out-of-tree code,
> whether it's a question on the usage of some standard in-tree
> function, a request for help with a coding or debugging problem,
> or out-of-tree repercussions of an in-tree change, he or she
> invariably has to put up with an answer along the lines of: "put
> your code into the tree and all your problems will be solved" -
> or its sarcastic variant: "I can't find your code anywhere in
> the current kernel sources".
> 
> You can't have it both ways. Either you go around bashing
> people for maintaining their code out-of-tree or you go around
> bashing people for trying to get their code into the tree.

You have a point.

But:
Code in the kernel must fulfill some (not completely fixed) quality 
criteria. It wouldn't be good to blindly include every bit of GPL'ed 
kernel code available anywhere in the Internet.

As an example, it's highly unlikely that some external device driver 
will be accepted without the author/maintainer doing some changes for 
getting it included.

If [1] AppArmor is considered to be generally insecure or in all 
respects inferior to SELinux it doesn't belong into the kernel.

Being blessed with some of the holy penguin pee by being included in the 
kernel is considered by many users as a quality criteria.

Sure, this contradicts a bit the "get your code upstream" mantra, but 
these are two conflicting goals and there's therefore no ideal solution.

If [1] AppArmor is offering required functionality not available through 
SELinux and it's considered a correct and secure solution for these 
purposes it should go into the kernel. Otherwise, it should not go into 
the kernel.

cu
Adrian

[1] note the "if"

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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