linux-kernel - Re: [AppArmor 00/45] 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:	Fri, 26 Oct 2007 15:16:53 -0700
From:	Crispin Cowan <crispin@...spincowan.com>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Andreas Gruenbacher <agruen@...e.de>, jjohansen@...e.de,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: [AppArmor 00/45] AppArmor security module overview

Arjan van de Ven wrote:
> My main concern for now is a description of what it tries to protect
> against/in what cases you would expect to use it. THe reason for asking
> this explicitly is simple: Until now the LSM discussions always ended
> up in a nasty mixed up mess around disagreeing on the theoretical model
> of what to protect against and the actual implementation of the threat
> protection. THe only way I can think of to get out of this mess is to
> have the submitter of the security model give a description of what his
> protection model is (and unless it's silly, not argue about that), and
> then only focus on how the code manages to achieve this model, to make
> sure there's no big gaps in it, within its own goals/reference.
>   
I really, really like this proposal. It is essentially what I have
always wanted.

> On the first part (discussion of the model) I doubt we can get people
> to agree, that's pretty much phylosophical... on the second part (how
> well the code/design lives up to its own goals) the analysis can be
> objective and technical.
>   
I will try to do that as soon as possible. While I will strive to be
both clear and precise, achieving both is challenging. So, if someone
discovers a mis-match between the description and the code, would a
patch to the description be an acceptable resolution, if it did not
render the model silly?

Crispin

-- 
Crispin Cowan, Ph.D.               http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work

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