Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Linux>
  3. Kernel
1 2  View All
[AppArmor 00/44] AppArmor security module overview
jjohansen at suse
Jun 26, 2007, 4:07 PM
Post #1 of 26 (2405 views)
Permalink
This post contains patches to include the AppArmor application security
framework, with request for inclusion into -mm for wider testing.

These patches are currently against lkml but we will gladly rebase them
against -mm so that they will apply cleanly.

Any comments and feedback to improve implementation are appreciated.

A second post dealing with the issue of passing NULL nameidata, will be
posted to lkml for discussion.

Changes since previous post:
- remove custom pathname mangling
- rework apparmor auditing to cleanup message formating and better
use audit framework
- change permission consistency checks from runtime to once at policy load
- add change_profile feature and cleanup change_hat to use change_profile

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.

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

Explaining the AppArmor design in detail would take by far too much
space here, so let me refer you to the technical documentation for that.
Included is a low-level walk-through of the system and basic tools, and
some examples. The manual pages included in the apparmor-parser package
are worth a read as well.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
akpm at linux-foundation
Jun 26, 2007, 4:52 PM
Post #2 of 26 (2240 views)
Permalink
On Tue, 26 Jun 2007 16:07:56 -0700
jjohansen@suse.de wrote:

> This post contains patches to include the AppArmor application security
> framework, with request for inclusion into -mm for wider testing.

Patches 24 and 31 didn't come through.

Rolled-up diffstat (excluding 24&31):

fs/attr.c | 7
fs/dcache.c | 181 ++-
fs/ecryptfs/inode.c | 41
fs/exec.c | 3
fs/fat/file.c | 2
fs/hpfs/namei.c | 2
fs/namei.c | 115 +-
fs/nfsd/nfs4recover.c | 7
fs/nfsd/nfs4xdr.c | 2
fs/nfsd/vfs.c | 89 +
fs/ntfs/file.c | 2
fs/open.c | 50
fs/reiserfs/file.c | 2
fs/reiserfs/xattr.c | 8
fs/splice.c | 4
fs/stat.c | 2
fs/sysfs/file.c | 2
fs/utimes.c | 11
fs/xattr.c | 75 -
fs/xfs/linux-2.6/xfs_lrw.c | 2
include/linux/audit.h | 12
include/linux/fs.h | 27
include/linux/nfsd/nfsd.h | 3
include/linux/security.h | 182 ++-
include/linux/sysctl.h | 2
include/linux/xattr.h | 11
ipc/mqueue.c | 2
kernel/audit.c | 6
kernel/sysctl.c | 27
mm/filemap.c | 12
mm/filemap_xip.c | 2
mm/shmem.c | 2
mm/tiny-shmem.c | 2
net/unix/af_unix.c | 2
security/Kconfig | 1
security/Makefile | 1
security/apparmor/Kconfig | 10
security/apparmor/Makefile | 13
security/apparmor/apparmor.h | 265 +++++
security/apparmor/apparmorfs.c | 252 +++++
security/apparmor/inline.h | 211 ++++
security/apparmor/list.c | 94 +
security/apparmor/locking.txt | 68 +
security/apparmor/lsm.c | 817 ++++++++++++++++
security/apparmor/main.c | 1255 +++++++++++++++++++++++++
security/apparmor/match.c | 248 ++++
security/apparmor/match.h | 83 +
security/apparmor/module_interface.c | 589 +++++++++++
security/apparmor/procattr.c | 155 +++
security/commoncap.c | 7
security/dummy.c | 43
security/selinux/hooks.c | 94 -
52 files changed, 4701 insertions(+), 404 deletions(-)

which seems OK.


so... where do we stand with this? Fundamental, irreconcilable
differences over the use of pathname-based security?

Are there any other sticking points?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
jjohansen at suse
Jun 26, 2007, 7:24 PM
Post #3 of 26 (2231 views)
Permalink
On Tue, Jun 26, 2007 at 04:52:02PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 16:07:56 -0700
> jjohansen@suse.de wrote:
>
> > This post contains patches to include the AppArmor application security
> > framework, with request for inclusion into -mm for wider testing.
>
> Patches 24 and 31 didn't come through.
>
yes, sorry about that I had a very odd failure authetication failure
with those two mails and missed it.

They have been recent.

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

> Are there any other sticking points?
>
>
The conditional passing of the vfsmnt mount in the vfs, as done in this
patch series, has received a NAK. This problem results from NFS passing
a NULL nameidata into the vfs. We have a second patch series that we
have posted for discussion that addresses this by splitting the nameidata
struct.
Message-Id: <20070626231510.883881222@suse.de>
Subject: [RFD 0/4] AppArmor - Don't pass NULL nameidata to
vfs_create/lookup/permission IOPs

other issues that have been raised are:
- AppArmor does not currently mediate IPC and network communications.
Mediation of these is a wip
- the use of d_path to generate the pathname used for mediation when a
file is opened.
- Generating the pathname using a reverse walk is considered ugly
- A buffer is alloced to store the generated path name.
- The buffer size has a configurable upper limit which will cause
opens to fail if the pathname length exceeds this limit. This
is a fail closed behavior.
- there have been some concerns expressed about the performance
of this approach
We are evaluating our options on how best to address this issue.
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
akpm at linux-foundation
Jun 26, 2007, 7:47 PM
Post #4 of 26 (2235 views)
Permalink
On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <jjohansen@suse.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.

Sigh. Please don't put us in this position again. Get stuff upstream
before shipping it to customers, OK? It ain't rocket science.

> > Are there any other sticking points?
> >
> >
> The conditional passing of the vfsmnt mount in the vfs, as done in this
> patch series, has received a NAK. This problem results from NFS passing
> a NULL nameidata into the vfs. We have a second patch series that we
> have posted for discussion that addresses this by splitting the nameidata
> struct.
> Message-Id: <20070626231510.883881222@suse.de>
> Subject: [RFD 0/4] AppArmor - Don't pass NULL nameidata to
> vfs_create/lookup/permission IOPs
>
> other issues that have been raised are:
> - AppArmor does not currently mediate IPC and network communications.
> Mediation of these is a wip
> - the use of d_path to generate the pathname used for mediation when a
> file is opened.
> - Generating the pathname using a reverse walk is considered ugly
> - A buffer is alloced to store the generated path name.
> - The buffer size has a configurable upper limit which will cause
> opens to fail if the pathname length exceeds this limit. This
> is a fail closed behavior.
> - there have been some concerns expressed about the performance
> of this approach
> We are evaluating our options on how best to address this issue.

OK, useful summary, thanks. I'd encourage you to proceed apace.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
jjohansen at suse
Jun 26, 2007, 11:43 PM
Post #5 of 26 (2226 views)
Permalink
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@suse.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.
>
sorry about that

> Do you agree with the "irreconcilable" part? I think I do.
>
I will concede that this may be the case for some. However I am still
hopeful (perhaps naive) that this isn't the case in general.

> 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.
Agreed, and I hope any changes that are made are for the benefit
of the kernel in general and will find uses in other parts.

>
> 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.
>
> Sigh. Please don't put us in this position again. Get stuff upstream
> before shipping it to customers, OK? It ain't rocket science.
>
Indeed, I can only appologize for the past, and offer reassurances
that we intend to do our best to do, it right going forward.

> > > Are there any other sticking points?
> > >
> > >
> > The conditional passing of the vfsmnt mount in the vfs, as done in this
> > patch series, has received a NAK. This problem results from NFS passing
> > a NULL nameidata into the vfs. We have a second patch series that we
> > have posted for discussion that addresses this by splitting the nameidata
> > struct.
> > Message-Id: <20070626231510.883881222@suse.de>
> > Subject: [RFD 0/4] AppArmor - Don't pass NULL nameidata to
> > vfs_create/lookup/permission IOPs
> >
> > other issues that have been raised are:
> > - AppArmor does not currently mediate IPC and network communications.
> > Mediation of these is a wip
> > - the use of d_path to generate the pathname used for mediation when a
> > file is opened.
> > - Generating the pathname using a reverse walk is considered ugly
> > - A buffer is alloced to store the generated path name.
> > - The buffer size has a configurable upper limit which will cause
> > opens to fail if the pathname length exceeds this limit. This
> > is a fail closed behavior.
> > - there have been some concerns expressed about the performance
> > of this approach
> > We are evaluating our options on how best to address this issue.
>
> OK, useful summary, thanks. I'd encourage you to proceed apace.

thankyou
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
mrmacman_g4 at mac
Jun 27, 2007, 3:58 AM
Post #6 of 26 (2232 views)
Permalink
On Jun 26, 2007, at 22:24:03, John Johansen wrote:
> other issues that have been raised are:
> - the use of d_path to generate the pathname used for mediation when a
> file is opened.
> - Generating the pathname using a reverse walk is considered ugly

A little more than "ugly". In this basic concurrent rename() and
path-lookup load:

mkdir -p /a/b/0
mkdir -p /a/b/2
mkdir -p /c
touch /a/b/0/1

cd /a/b
while true; mv 0/1 2/3; mv 2/3 0/1; done &
cd /
while true; do mv a/b c/d; mv c/d a/b; done &
while true; do cat a/b/0/1 & done
while true; do cat a/b/2/3 & done
while true; do cat c/d/0/1 & done
while true; do cat c/d/2/3 & done

I seem to recall you could actually end up racing and building a path
to the file in those directories as "a/d/0/3" or some other path at
which it never even remotely existed. I'd love to be wrong, but I
can't help but see this problem in any reverse-pathname-generation
proposal which gets the locking right.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
agruen at suse
Jun 27, 2007, 6:37 AM
Post #7 of 26 (2221 views)
Permalink
On Wednesday 27 June 2007 12:58, Kyle Moffett wrote:
> I seem to recall you could actually end up racing and building a path
> to the file in those directories as "a/d/0/3" or some other path at
> which it never even remotely existed. I'd love to be wrong,

Cheer up, you recall wrong.

> but I can't help but see this problem in any reverse-pathname-generation
> proposal which gets the locking right.

Have a look at how __d_path() is implemented (with the fixes): It takes the
dcache_lock, and the vfsmount_lock where necessary, and this ensures that the
pathname can't change under it, neither because of a rename nor unlink nor
remount. The pathname computed is *exactly* the name the file has at that
specific point time.

A few more details about how pathnames work are explained in the tech doc at:
http://forge.novell.com/modules/xfcontent/downloads.php/apparmor/LKML_Submission-May_07

Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
bunk at stusta
Jun 27, 2007, 8:11 AM
Post #8 of 26 (2240 views)
Permalink
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@suse.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.

cu
Adrian

[1] note the "if"
[2] could be, but not necessarily, SELinux
[3] http://developer.novell.com/wiki/index.php/Apparmor_FAQ

--

"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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
crispin at novell
Jun 27, 2007, 2:06 PM
Post #9 of 26 (2222 views)
Permalink
Adrian Bunk wrote:
> On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
>
>> Do you agree with the "irreconcilable" part? I think I do.
I am hoping for a reconciliation where the people who don't like
AppArmor live with it by not using it. AppArmor is not intended to
replace SELinux, it is intended to address a different set of goals.

>> 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
>
We argue that the proposed patch is a viable solution for providing
AppArmor functionality. We would be happy for specific suggestions on
how to make it better.

> 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.
AppArmor's advantages come from the model, not the tools. AppArmor is
not inferior to SELinux, it is different than SELinux. Neither can
replace the other without horrid kludges.

Crispin

--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
seanlkml at sympatico
Jun 27, 2007, 2:29 PM
Post #10 of 26 (2221 views)
Permalink
On Wed, 27 Jun 2007 14:06:04 -0700
Crispin Cowan <crispin@novell.com> wrote:

> I am hoping for a reconciliation where the people who don't like
> AppArmor live with it by not using it. AppArmor is not intended to
> replace SELinux, it is intended to address a different set of goals.

You keep saying that. But for that to be true you'd have to believe
_everyone_ using Novell distributions has needs that align exactly
with AppArmor. Otherwise, how to explain that you don't offer and
support both SELinux and AppArmor to your users?

It seems as far as Novell is concerned, AppArmor _is_ meant to replace
SELinux. Not that there is really anything wrong with that, but it's
a little disingenuous to then argue that they're meant to coexist.

Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
adilger at clusterfs
Jun 27, 2007, 3:41 PM
Post #11 of 26 (2219 views)
Permalink
Any chance you can remove linux-fsdevel from the CC list? I don't think this
has anything to do with filesystems.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
crispin at novell
Jun 27, 2007, 3:46 PM
Post #12 of 26 (2229 views)
Permalink
Sean wrote:
> On Wed, 27 Jun 2007 14:06:04 -0700
> Crispin Cowan <crispin@novell.com> wrote:
>
>> I am hoping for a reconciliation where the people who don't like
>> AppArmor live with it by not using it. AppArmor is not intended to
>> replace SELinux, it is intended to address a different set of goals.
>>
> You keep saying that. But for that to be true you'd have to believe
> _everyone_ using Novell distributions has needs that align exactly
> with AppArmor. Otherwise, how to explain that you don't offer and
> support both SELinux and AppArmor to your users?
>
They are meant to co-exist in the Linux kernel source tree.

It is a fact that there exist use cases where AppArmor is incapable of
meeting the need and SELinux is just the right thing. It is Novell's
business judgment that there are not enough of those situations in our
customer base to be worth the additional expense at this time.

But we do not want to prevent other people from using SELinux if it
suits them. Linux is about choice, and that is especially vital in
security. As Linus himself observed when LSM was started, there are a
lot of security models, they have various strengths and weaknesses, and
often are not compatible with each other. That is why it is important
that LSM persist, that SELinux not be the only in-tree user of LSM, and
why we think AppArmor should be included upstream, so that non-SUSE
users can also use AppArmor if it suits them.

Crispin

--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
davem at davemloft
Jun 27, 2007, 4:05 PM
Post #13 of 26 (2219 views)
Permalink
From: Crispin Cowan <crispin@novell.com>
Date: Wed, 27 Jun 2007 15:46:57 -0700

> But we do not want to prevent other people from using SELinux if it
> suits them. Linux is about choice, and that is especially vital in
> security. As Linus himself observed when LSM was started, there are a
> lot of security models, they have various strengths and weaknesses, and
> often are not compatible with each other. That is why it is important
> that LSM persist, that SELinux not be the only in-tree user of LSM, and
> why we think AppArmor should be included upstream, so that non-SUSE
> users can also use AppArmor if it suits them.

Anyone can apply the apparmour patch to their tree, they get the
choice that way. Nobody is currently prevented from using apparmour
if they want to, any such suggestion is pure rubbish.

It is even more incredulious to imply that just by having apparmour
in the upstream kernel all the userland bits will magically appear
on every user's distribution.

Give me a break.

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.

Frankly I think AppArmour is a joke, and all of this integration with
LSM business is just a face saving effort, nothing more. And saving
face is not, and has never been, a reason for something to be put into
the upstream tree.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
casey at schaufler-ca
Jun 27, 2007, 5:27 PM
Post #14 of 26 (2225 views)
Permalink
--- David Miller <davem@davemloft.net> wrote:

> From: Crispin Cowan <crispin@novell.com>
> Date: Wed, 27 Jun 2007 15:46:57 -0700
>
> > But we do not want to prevent other people from using SELinux if it
> > suits them. Linux is about choice, and that is especially vital in
> > security. As Linus himself observed when LSM was started, there are a
> > lot of security models, they have various strengths and weaknesses, and
> > often are not compatible with each other. That is why it is important
> > that LSM persist, that SELinux not be the only in-tree user of LSM, and
> > why we think AppArmor should be included upstream, so that non-SUSE
> > users can also use AppArmor if it suits them.
>
> Anyone can apply the apparmour patch to their tree, they get the
> choice that way. Nobody is currently prevented from using apparmour
> if they want to, any such suggestion is pure rubbish.

The exact same argument was made prior to SELinux going upstream.
Look, if you can't be right, try at least to be original.

> It is even more incredulious to imply that just by having apparmour
> in the upstream kernel all the userland bits will magically appear
> on every user's distribution.

Just like all the SELinux userland magically appeared in everyone's
distribution? Nope, didn't happen.

> Give me a break.

No. You are out of line and spewing ignorance.

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

Duh. Those are pretty much the reasons anyone goes through the
trouble of getting anything upstream.

> Neither of those are reasons why something should go into the tree.

They reflect the corporate reality of the open source community.
If you're going to go down the "open source isn't for money"
rathole please take it elsewhere. I've heard the arguments so many
times I can sing them to the tune of "Lady Madonna".

> Frankly I think AppArmour is a joke,

"SELinux, AppArmor, and Hilary Clinton walk into a bar ..."

> and all of this integration with
> LSM business is just a face saving effort, nothing more. And saving
> face is not, and has never been, a reason for something to be put into
> the upstream tree.

Believe what you will. Crispin has been working with LSM from the
inception those many years ago. He's been working on getting this
module in for over a year. If you don't like his module go write
your own and put him out of business.


Casey Schaufler
casey@schaufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
davem at davemloft
Jun 27, 2007, 5:34 PM
Post #15 of 26 (2226 views)
Permalink
From: Casey Schaufler <casey@schaufler-ca.com>
Date: Wed, 27 Jun 2007 17:27:17 -0700 (PDT)

> --- David Miller <davem@davemloft.net> wrote:
>
> > Neither of those are reasons why something should go into the tree.
>
> They reflect the corporate reality of the open source community.
> If you're going to go down the "open source isn't for money"
> rathole please take it elsewhere. I've heard the arguments so many
> times I can sing them to the tune of "Lady Madonna".

That's a wonderful technical reason for apparmour to go into the tree.
Thanks for sharing and making it even clearer what is really behind
this submission.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
alan at lxorguk
Jun 28, 2007, 3:23 AM
Post #16 of 26 (2220 views)
Permalink
> > Anyone can apply the apparmour patch to their tree, they get the
> > choice that way. Nobody is currently prevented from using apparmour
> > if they want to, any such suggestion is pure rubbish.
>
> The exact same argument was made prior to SELinux going upstream.

Its made for every thing before it goes upstream. It shouldn't be going
uptream until it works, is reliable and does something useful. Then if it
ever makes that grade it can go and sit in -mm for a bit to shake down .

> > Frankly I think AppArmour is a joke,
>
> "SELinux, AppArmor, and Hilary Clinton walk into a bar ..."


SELinux orders a beer object
AppArmor order a /beer
Hilary says "You are both under 21 you can't"
SELinux orders a shandy object
AppArmor orders a /shandy

SELinux is refused because the shandy mixer opened a beer object and
shandy inherited beer typing
AppArmor gets drunk because /shandy and /beer are clearly different


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
tilman at imap
Jun 28, 2007, 4:27 AM
Post #17 of 26 (2216 views)
Permalink
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.

--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

Attached Files:

Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
bunk at stusta
Jun 28, 2007, 5:48 AM
Post #18 of 26 (2226 views)
Permalink
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
billodo at sgi
Jun 28, 2007, 6:50 AM
Post #19 of 26 (2214 views)
Permalink
On Wed, Jun 27, 2007 at 05:27:17PM -0700, Casey Schaufler wrote:
|
| --- David Miller <davem@davemloft.net> wrote:
|
| > From: Crispin Cowan <crispin@novell.com>
| > Date: Wed, 27 Jun 2007 15:46:57 -0700
| >
| > > But we do not want to prevent other people from using SELinux if it
| > > suits them. Linux is about choice, and that is especially vital in
| > > security. As Linus himself observed when LSM was started, there are a
| > > lot of security models, they have various strengths and weaknesses, and
| > > often are not compatible with each other. That is why it is important
| > > that LSM persist, that SELinux not be the only in-tree user of LSM, and
| > > why we think AppArmor should be included upstream, so that non-SUSE
| > > users can also use AppArmor if it suits them.
| >
| > Anyone can apply the apparmour patch to their tree, they get the
| > choice that way. Nobody is currently prevented from using apparmour
| > if they want to, any such suggestion is pure rubbish.
|
| The exact same argument was made prior to SELinux going upstream.
| Look, if you can't be right, try at least to be original.
|
| > It is even more incredulious to imply that just by having apparmour
| > in the upstream kernel all the userland bits will magically appear
| > on every user's distribution.
|
| Just like all the SELinux userland magically appeared in everyone's
| distribution? Nope, didn't happen.
|
| > Give me a break.
|
| No. You are out of line and spewing ignorance.

Please.
I really wish this thread would stick to the technical matter and
dispense with the infernile sniping on one hand and stroking of
egos on the other. Sheesh - some of us are actually trying to glean
something useful from all of this.

|
| > 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.
|
| Duh. Those are pretty much the reasons anyone goes through the
| trouble of getting anything upstream.
|
| > Neither of those are reasons why something should go into the tree.
|
| They reflect the corporate reality of the open source community.
| If you're going to go down the "open source isn't for money"
| rathole please take it elsewhere. I've heard the arguments so many
| times I can sing them to the tune of "Lady Madonna".
|
| > Frankly I think AppArmour is a joke,
|
| "SELinux, AppArmor, and Hilary Clinton walk into a bar ..."

Yawn. Not funny. See above comment.

| > and all of this integration with
| > LSM business is just a face saving effort, nothing more. And saving
| > face is not, and has never been, a reason for something to be put into
| > the upstream tree.
|
| Believe what you will. Crispin has been working with LSM from the
| inception those many years ago. He's been working on getting this
| module in for over a year. If you don't like his module go write
| your own and put him out of business.

Now this is getting really boring. See above comment.
Can't we just stay on point?

--
Bill O'Donnell
SGI
billodo@sgi.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
pavel at ucw
Jun 29, 2007, 11:06 AM
Post #20 of 26 (2145 views)
Permalink
Hi!

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

If this is merged, suse is stuck with technically inferior solution
forever. This may please parts of suse, but not our users.

If this is not merged, suse will [have to] work with selinux people to
come up with friendlier userland tools/selinux improvements. (We
already had discussions with vojtech about a way to add path-based
aspects to selinux, and selinux people already offered to add 'new
file label is function of directory label and new name' support, which
addresses lots of reasons for AA).

Actually, there's a middle way. Merging only 'pass vfsmounts down'
parts will make AA self contained enough that suse will not go crazy
while trying to maintain it, but will have good enough incentive to
work with selinux people on something better.

Pavel
(not speaking for suse,
as usual).
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
ebiederm at xmission
Jul 2, 2007, 9:45 AM
Post #21 of 26 (2170 views)
Permalink
Adrian Bunk <bunk@stusta.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@suse.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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
casey at schaufler-ca
Jul 2, 2007, 12:31 PM
Post #22 of 26 (2171 views)
Permalink
--- "Eric W. Biederman" <ebiederm@xmission.com> wrote:



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

More likely -EACCES, but otherwise not so terribly far off.

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

It's a deficiency of the file system semantics invented by
Kernighan, Thompson, et. al. in the later 1970's, favoring
speed and size of implementation over a pristine namespace.
The LSM is reasonably faithfull in presenting both the good
and the bad of the file system semantics.

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

While that is true of SELinux and AppArmor I would suggest that
is an artifact of the design goals of those two sophisticated
security schemes, not an attribute of the LSM.

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

Weeeelllll ... Module stacking has been a contentious issue from
day one of the LSM. Now that SELiunx is proposing to take over
capability processing for it's own purposes it's easy to think
that while other schemes may be up to stacking SELinux ain't gonna.

> So it seems clear that if we are aiming at an ideal solution. We
> first need to enhance the LSM.

I don't think so. I see much greater social/political problems
than I see technical ones.

> Then merge in the AppArmor
> functionality. Doing it all in one patch series looks to overwhelming
> for a decent code review.

It's true that the code review for AppArmor has proven difficult.
That's going to be true of any change to the vfs layer, for any
reason. Have someone who was there tell you about the original XFS
proposals some time. Again, it's not LSM's fault.

> That said is anyone interested in making the LSM more like iptables
> with a generic table based rules structure?

That's pretty close to what you get with SELinux, and one reason
why that crowd has advocated that LSM be dumped in favor of SELinux
as the sole interface.

> That way we could fix
> the one true LSM problem and concentrate on simpler pieces that give
> specific bits of interesting functionality.

Sort of. While the SELinux kernel code isn't much, less than 20k lines,
the reference policy it requires is 200k lines, and the smallest policy
I've ever heard anyone claim runs is 600. Yes, you get interesting
functionality, but I don't recall there being many claims that policy
development is simple of late.

> Or at the very least
> be able to compile in multiple different bits of functionality into
> the kernel simultaneously.

The LSM stacking problem, to my mind, is waiting on two modules that
really want to work together and enough thick skin to get past those
who don't want LSM to get better in hopes it will go away.

> I'm really not familiar with the security issues the LSM addresses

It addresses none, it is a tool put in place so that Linus doesn't
have to listen to security people argue over which scheme is better.

> but I do know, it encourages huge incompatible mega solutions,

That's the security marketplace, not LSM.

> and
> it tends to break when I fix real security problems in the kernel.

Please, examples.

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

The "additional" architecture of the LSM, as opposed to the originally
proposed "authoritative" model is responsible for a good deal of the
limited deficiency and uasability, but was considered necessary to
prevent kernel "highjacking". If it's fragile, it's mostly due to the
organic growth of security implementation in the kernel. It is under
utilized, and there are a number of reasons for that, but recent events
are encouraging.


Casey Schaufler
casey@schaufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
hch at infradead
Jul 2, 2007, 1:15 PM
Post #23 of 26 (2169 views)
Permalink
On Mon, Jul 02, 2007 at 12:31:49PM -0700, Casey Schaufler wrote:
> It's true that the code review for AppArmor has proven difficult.
> That's going to be true of any change to the vfs layer, for any
> reason. Have someone who was there tell you about the original XFS
> proposals some time. Again, it's not LSM's fault.

Utterly wrong comparism. There haven't been any VFS changes for XFS.
There has been some new functionality in the core kernel, but the
more interesting bits where in the VM (e.g. vmap which is now widely
used).

AA on the other hand just fucks up VFS layering to implement really dumb
semantics.

A better comparism would be to some of the original reiser4 suggestions,
although to be as bad you'd have to look at Hans' whitepapers and not
actually existing code. And yes, there's a reason his pipedreams never
got anywhere near merged.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
casey at schaufler-ca
Jul 2, 2007, 2:09 PM
Post #24 of 26 (2191 views)
Permalink
--- Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Jul 02, 2007 at 12:31:49PM -0700, Casey Schaufler wrote:
> > It's true that the code review for AppArmor has proven difficult.
> > That's going to be true of any change to the vfs layer, for any
> > reason. Have someone who was there tell you about the original XFS
> > proposals some time. Again, it's not LSM's fault.
>
> Utterly wrong comparism. There haven't been any VFS changes for XFS.

Ah, I suggested the original proposal, not what actually got in.
Two very different things. The XFS developers listened to the initial
feedback and, after picking themselves up off the floor, got up and
adjusted their plans.

> There has been some new functionality in the core kernel, but the
> more interesting bits where in the VM (e.g. vmap which is now widely
> used).
>
> AA on the other hand just fucks up VFS layering to implement really dumb
> semantics.
>
> A better comparism would be to some of the original reiser4 suggestions,
> although to be as bad you'd have to look at Hans' whitepapers and not
> actually existing code. And yes, there's a reason his pipedreams never
> got anywhere near merged.

Agreed that the further up you want to mess things the tougher the
task you have ahead of you. That's what I was hoping to get across,
but it looks as if you have better, more recent examples than what
I offered.

Thank you.


Casey Schaufler
casey@schaufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview [ In reply to ]
davej at redhat
Jul 2, 2007, 11:20 PM
Post #25 of 26 (2162 views)
Permalink
On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:

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

How is this different from Red Hat wearing the permanent cost of
carrying Execshield or other vetoed-by-upstream features ?

Given the choice, I'd ship a kernel for Fedora with nothing added
that isn't upstream, but we have something of a legacy from our
dumber days. (Though we've managed to drop lots of the more invasive
stuff over time thankfully.. 4g4g for eg).

> Sigh. Please don't put us in this position again. Get stuff upstream
> before shipping it to customers, OK? It ain't rocket science.

Indeed. The idea of granting exceptions to our usual acceptance
criteria just because "some distro shipped it" strikes me as wrong
on so many levels, regardless of its technical flaws.

And this isn't just because this is a patch from a competitor,
I'd expect the exact same criteria to be applied if I tried
to ram execshield etc down everyones throats.

Dave

--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
1 2  View All

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal