Re: AppArmor Security Goal

2007-11-11 Thread Rob Meijer
On Sat, November 10, 2007 22:04, Andi Kleen wrote: > Crispin Cowan <[EMAIL PROTECTED]> writes: > > The document should be a good base for a merge. > >> * A confined process can operate on a file descriptor passed to it >> by an unconfined process, even if it manipulates a file not in the

Re: AppArmor Security Goal

2007-11-11 Thread Rob Meijer
On Sat, November 10, 2007 22:04, Andi Kleen wrote: Crispin Cowan [EMAIL PROTECTED] writes: The document should be a good base for a merge. * A confined process can operate on a file descriptor passed to it by an unconfined process, even if it manipulates a file not in the

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

2007-10-29 Thread Rob Meijer
On Mon, October 29, 2007 11:24, Crispin Cowan wrote: >> Thus IMHO it may be a good idea to instead of a maintainer for LSM >> modules as proposed, alternatively a maintainer for each formal model >> may be more appropriate. This also would require module builders to >> first >> think about what

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

2007-10-29 Thread Rob Meijer
On Thu, October 25, 2007 02:42, Casey Schaufler wrote: > > I agree that security code does need to provide security. What we > need to get away from is the automatic attacks that are based on 20th > century computer system assumptions. Things like "name based access > control is rediculous", and

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

2007-10-29 Thread Rob Meijer
On Thu, October 25, 2007 02:42, Casey Schaufler wrote: I agree that security code does need to provide security. What we need to get away from is the automatic attacks that are based on 20th century computer system assumptions. Things like name based access control is rediculous, and a module

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

2007-10-29 Thread Rob Meijer
On Mon, October 29, 2007 11:24, Crispin Cowan wrote: Thus IMHO it may be a good idea to instead of a maintainer for LSM modules as proposed, alternatively a maintainer for each formal model may be more appropriate. This also would require module builders to first think about what formal

Re: AppArmor FAQ

2007-04-18 Thread Rob Meijer
On Wed, April 18, 2007 14:15, Joshua Brindle wrote: >> Having said that, I feel a path based solution could have great >> potential >> if it could be used in conjunction with the object capability model, >> that >> I would consider a simple and practical alternative integrity model that >> does

Re: AppArmor FAQ

2007-04-18 Thread Rob Meijer
On Tue, April 17, 2007 23:55, Karl MacMillan wrote: > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: >> On Mon, 16 Apr 2007, John Johansen wrote: >> >> > Label-based security (exemplified by SELinux, and its predecessors in >> > MLS systems) attaches security policy to the data. As the

Re: AppArmor FAQ

2007-04-18 Thread Rob Meijer
On Tue, April 17, 2007 23:55, Karl MacMillan wrote: On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: On Mon, 16 Apr 2007, John Johansen wrote: Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows

Re: AppArmor FAQ

2007-04-18 Thread Rob Meijer
On Wed, April 18, 2007 14:15, Joshua Brindle wrote: Having said that, I feel a path based solution could have great potential if it could be used in conjunction with the object capability model, that I would consider a simple and practical alternative integrity model that does not require

Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

2007-04-17 Thread Rob Meijer
On Mon, April 16, 2007 23:57, Alan Cox wrote: >> > That is a fairly significant and sudden change to the existing >> > kernel/user interface. >> >> Well, this is not meant for 2.6.21. I hope it is possible to change it >> in >> early 2.6.22; otherwise if we can't fix mistakes from the past we are

Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

2007-04-17 Thread Rob Meijer
On Mon, April 16, 2007 23:57, Alan Cox wrote: That is a fairly significant and sudden change to the existing kernel/user interface. Well, this is not meant for 2.6.21. I hope it is possible to change it in early 2.6.22; otherwise if we can't fix mistakes from the past we are pretty

Re: [AppArmor 00/41] AppArmor security module overview

2007-04-13 Thread Rob Meijer
I've posted on the subject before, and as noone seemed to truely relate to the concept I concequently dropped my effords, but as you seem to be half a step in the general right direction, this may be a good time to bring it up again. If instead of 'least privilege' and fat profiles, you would opt

Re: [AppArmor 00/41] AppArmor security module overview

2007-04-13 Thread Rob Meijer
I've posted on the subject before, and as noone seemed to truely relate to the concept I concequently dropped my effords, but as you seem to be half a step in the general right direction, this may be a good time to bring it up again. If instead of 'least privilege' and fat profiles, you would opt