-- 

-

[ message continues ]

On Thu, Oct 25, 2007 at 11:40:24PM -0700, jjohansen@suse.de wrote:
Sorry this got dropped some how.

This submission of the AppArmor security module is based against -mm.

Any comments and feedback to improve implementation are appreciated.

The patch series consists of five areas:

 (1) Pass struct vfsmount through to LSM hooks.

 (2) Fixes and improvements to __d_path():

     (a) make it unambiguous and exclude unreachable paths from
         /proc/mounts,

     (b) make its result consistent in the face of remounts,

     (c) introduce d_namespace_path(), a variant of d_path that goes up
         to the namespace root instead of the chroot.

     (d) the behavior of d_path() and getcwd() remain unchanged, and
     there is no hidding of unreachable paths in /proc/mounts.  The
     patches addressing these have been seperated from the AppArmor
     submission and will be introduced at a later date.
=20
     Part (a) has been in the -mm tree for a while; this series includes
     an updated copy of the -mm patch. Parts (b) and (c) shouldn't be too
     controversial.

 (3) Be able to distinguish file descriptor access from access by name
     in LSM hooks.

     Applications expect different behavior from file descriptor
     accesses and accesses by name in some cases. We need to pass this
     information down the LSM hooks to allow AppArmor to tell which is
     which.

 (4) Convert the selinux sysctl pathname computation code into a standalone
     function.

 (5) The AppArmor LSM itself.

     (See below.)

A tarball of the kernel patches, base user-space utilities, example
profiles, and technical documentation (including a walk-through) are
available at:

  http://forgeftp.novell.com/apparmor/LKML_Submission-Oct-07/

Only the most recent features are covered in brief here for a more
complete explaination please refere to the technical documentation.

Changes since previous submission
- fix wrong error code for failed pathname
- fix change_profile ...
[ message continues ]

On Thu, 25 Oct 2007 23:40:24 -0700
jjohansen@suse.de wrote:

before going into the LSM / security side of things, I'd like to get
the VFS guys to look at your VFS interaction code.

In addition, I'd like to ask you to put a file in Documentation/
somewhere that describes what AppArmor is intended security protection
is (it's different from SELinux for sure for example); by having such a
document for each LSM user, end users and distros can make a more
informed decision which module suits their requirements... and it also
makes it possible to look at the implementation to see if it has gaps
to the intent, without getting into a pissing contest about which
security model is better; but unless the security goals are explicitly
described that's a trap that will keep coming back... so please spend
some time on getting a good description going here..

-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
-

[ message continues ]

yes this is needed and a good idea in general

thanks
john
[ message continues ]

On Fri, 26 Oct 2007 11:34:48 -0700

would you mind posting your first stab at this to the list shortly,
because without that it's nearly impossible to review your patchkit in
a sensible way...
-

[ message continues ]

Hmm, I agree that it makes sense to give a short overview of each LSM. A 
description of the AppArmor model and implementation can be found in the 
directory that John referred to actually. I'm unsure how much of that makes 
sense under Documentation/ -- what do you think? 

 http://forgeftp.novell.com/apparmor/LKML_Submission-Oct-07/techdoc.pdf

I guess actual end user information doesn't belong in the kernel sources; that 
really seems wrong.

Thanks,
Andreas
-

[ message continues ]

On Fri, 26 Oct 2007 22:44:56 +0200

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.

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.


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
-

[ message continues ]

Okay, I see what you mean. Thanks.
-

[ message continues ]

I really, really like this proposal. It is essentially what I have
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

-

[ message continues ]

On Fri, 26 Oct 2007 15:16:53 -0700

I think it's entirely reasonable that if it turns out that the code
can't do a certain aspect of the envisioned security (eg not just a
code bug but a design level issue), the answer is to adjust the
vision...


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
-

[ message continues ]

It's been NACKed a few times, and just reposting it won't help.

-

[ message continues ]

Let me repeat what I have said before in another context. The past discussions 
on linux-kernel were useful for a while, and we got constructive feedback 
which we could act upon, but then the feedback became very non-constructive 
again, and you NACKed patches without giving any good reasons. I have asked 
for specific feedback but didn't get any in:

 - Rejecting the vfsmount additions,
   http://marc.info/?l=linux-kernel&m=118350187712375

 - VFS layering fuck-up accusation,
   http://marc.info/?l=linux-kernel&m=118348050804600

So can we pick up things there again, and have a real discussion about the 
things you criticize?

Thanks,
Andreas
-

[ message continues ]