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.
--
On Tue, 26 Jun 2007 16:07:56 -0700
[email protected] 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?
On Tue, Jun 26, 2007 at 04:52:02PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 16:07:56 -0700
> [email protected] 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: <[email protected]>
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.
On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <[email protected]> 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: <[email protected]>
> 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.
On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <[email protected]> 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: <[email protected]>
> > 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
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
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
On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <[email protected]> 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
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
On Wed, 27 Jun 2007 14:06:04 -0700
Crispin Cowan <[email protected]> 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
Sean wrote:
> On Wed, 27 Jun 2007 14:06:04 -0700
> Crispin Cowan <[email protected]> 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
From: Crispin Cowan <[email protected]>
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.
--- David Miller <[email protected]> wrote:
> From: Crispin Cowan <[email protected]>
> 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
[email protected]
From: Casey Schaufler <[email protected]>
Date: Wed, 27 Jun 2007 17:27:17 -0700 (PDT)
> --- David Miller <[email protected]> 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.
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.
> > 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
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: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
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
On Wed, Jun 27, 2007 at 05:27:17PM -0700, Casey Schaufler wrote:
|
| --- David Miller <[email protected]> wrote:
|
| > From: Crispin Cowan <[email protected]>
| > 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
[email protected]