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

[serge]

(finally starting to make headway through this thread over a month late)

Quoting Alan Cox ([EMAIL PROTECTED]):
> > To reject an LSM for providing "bad" security, IMHO you should have to
> > show how it is possible to subvert the self-stated goals of that LSM.
> > Complaints that the LSM fails to meet some goal outside of its stated
> > purpose is irrelevant. Conjecture that it probably can be violated
> > because of $contrivance is just so much FUD.
> 
> That seems to be an appropriate test.
> 
> > Exception: it is valid to say that the self-stated goal is too narrow to
> > be useful. But IMHO that bar of "too narrow" should be very, very low.
> > Defenses against specific modes of attack would be a fine thing to build
> > up in the library of LSMs, especially if we got a decent stacking module
> > so that they could be composed.
> 
> Once you have stacking then it actually at times will make sense to have
> security modules that do one very precise thing and do it well.

Hey - I thought it was the other way around?  :)

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[serge]

(finally starting to make headway through this thread over a month late)

Quoting Alan Cox ([EMAIL PROTECTED]):
  To reject an LSM for providing bad security, IMHO you should have to
  show how it is possible to subvert the self-stated goals of that LSM.
  Complaints that the LSM fails to meet some goal outside of its stated
  purpose is irrelevant. Conjecture that it probably can be violated
  because of $contrivance is just so much FUD.
 
 That seems to be an appropriate test.
 
  Exception: it is valid to say that the self-stated goal is too narrow to
  be useful. But IMHO that bar of too narrow should be very, very low.
  Defenses against specific modes of attack would be a fine thing to build
  up in the library of LSMs, especially if we got a decent stacking module
  so that they could be composed.
 
 Once you have stacking then it actually at times will make sense to have
 security modules that do one very precise thing and do it well.

Hey - I thought it was the other way around?  :)

-serge
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Serge E. Hallyn]

Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Peter Dolding wrote:
> > On 11/1/07, Casey Schaufler <[EMAIL PROTECTED]> wrote:
> >> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
> >> Posix capabilities predate SELinux. SELinux is not interested in
> >> Posix capabilities.
> >>
> >>> But no IBM had to do it.
> >> Err, no. It was done by Andrew Morgan back in the dark ages.
> >> Why on earth do you think IBM did it?
> > 
> > Posix file capabilities the option to replace SUID bit with something
> > more security safe only handing out segments of root power instead of
> > the complete box and dice like SUID.  Even different on a user by user
> > base.
> > 
> > Posix capabilites is what Posix file capabilities is based on.  Yes I
> > know the words appear close.  The word file is important.  Please read
> > Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html
> 
> For the record, I think you are both right. I took a stab at it back
> when Casey and I first met:
> 
> ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.4-fcap/README
> 
> all that stuff worked fine it was just a bit ahead of its time...
> 
> - From memory, at that point in time "extended attributes" were an
> external patch, and having some trouble getting merged. My sense was
> that EA was a pre-requisite and I was happy to wait for that support to
> become integrated before pushing my file capability support.
> 
> In the midst of all this LSM emerged as a reaction to Linus' clear
> unhappiness about all extensions security. I didn't have the time to
> participate in the LSM, and my work sat in the form of these patches.
> 
> SELinux at that time existed as a separate infrastructure, and evidently
> did have the time to embrace LSM.
> 
> > IBM coders worked and got it into the main line really recently to
> > provide at least some way to avoid fault of SUID of course it could
> 
> [...]
> 
> So, yes, IBM (Serge) deserve full credit for starting over, and getting
> it merged...

There are still pieces to line up.  Note that Andrew Morgan is working
on a patch to make the securebits per-process to make capabilities
more useful as well as a 64-bit capability patch.  And the support in
tree to date would be riddled with gotchas without Andrew Morgan's,
Stephen Smalley's, and Casey Schaufler's input.

-serge

(But hey, thanks :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Serge E. Hallyn]

Quoting Andrew Morgan ([EMAIL PROTECTED]):
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Peter Dolding wrote:
  On 11/1/07, Casey Schaufler [EMAIL PROTECTED] wrote:
  --- Peter Dolding [EMAIL PROTECTED] wrote:
  Posix capabilities predate SELinux. SELinux is not interested in
  Posix capabilities.
 
  But no IBM had to do it.
  Err, no. It was done by Andrew Morgan back in the dark ages.
  Why on earth do you think IBM did it?
  
  Posix file capabilities the option to replace SUID bit with something
  more security safe only handing out segments of root power instead of
  the complete box and dice like SUID.  Even different on a user by user
  base.
  
  Posix capabilites is what Posix file capabilities is based on.  Yes I
  know the words appear close.  The word file is important.  Please read
  Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html
 
 For the record, I think you are both right. I took a stab at it back
 when Casey and I first met:
 
 ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.4-fcap/README
 
 all that stuff worked fine it was just a bit ahead of its time...
 
 - From memory, at that point in time extended attributes were an
 external patch, and having some trouble getting merged. My sense was
 that EA was a pre-requisite and I was happy to wait for that support to
 become integrated before pushing my file capability support.
 
 In the midst of all this LSM emerged as a reaction to Linus' clear
 unhappiness about all extensions security. I didn't have the time to
 participate in the LSM, and my work sat in the form of these patches.
 
 SELinux at that time existed as a separate infrastructure, and evidently
 did have the time to embrace LSM.
 
  IBM coders worked and got it into the main line really recently to
  provide at least some way to avoid fault of SUID of course it could
 
 [...]
 
 So, yes, IBM (Serge) deserve full credit for starting over, and getting
 it merged...

There are still pieces to line up.  Note that Andrew Morgan is working
on a patch to make the securebits per-process to make capabilities
more useful as well as a 64-bit capability patch.  And the support in
tree to date would be riddled with gotchas without Andrew Morgan's,
Stephen Smalley's, and Casey Schaufler's input.

-serge

(But hey, thanks :)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Andrew Morgan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Dolding wrote:
> On 11/1/07, Casey Schaufler <[EMAIL PROTECTED]> wrote:
>> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
>> Posix capabilities predate SELinux. SELinux is not interested in
>> Posix capabilities.
>>
>>> But no IBM had to do it.
>> Err, no. It was done by Andrew Morgan back in the dark ages.
>> Why on earth do you think IBM did it?
> 
> Posix file capabilities the option to replace SUID bit with something
> more security safe only handing out segments of root power instead of
> the complete box and dice like SUID.  Even different on a user by user
> base.
> 
> Posix capabilites is what Posix file capabilities is based on.  Yes I
> know the words appear close.  The word file is important.  Please read
> Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html

For the record, I think you are both right. I took a stab at it back
when Casey and I first met:

ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.4-fcap/README

all that stuff worked fine it was just a bit ahead of its time...

- From memory, at that point in time "extended attributes" were an
external patch, and having some trouble getting merged. My sense was
that EA was a pre-requisite and I was happy to wait for that support to
become integrated before pushing my file capability support.

In the midst of all this LSM emerged as a reaction to Linus' clear
unhappiness about all extensions security. I didn't have the time to
participate in the LSM, and my work sat in the form of these patches.

SELinux at that time existed as a separate infrastructure, and evidently
did have the time to embrace LSM.

> IBM coders worked and got it into the main line really recently to
> provide at least some way to avoid fault of SUID of course it could

[...]

So, yes, IBM (Serge) deserve full credit for starting over, and getting
it merged...

Cheers

Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFHLr6EQheEq9QabfIRAsOrAJ9XzTL0Lqm5jaxwO6UoPB9Pwh3SzQCfVWFd
cPyjsGp/s6D6HuBE6M4NJH0=
=G/ah
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Tetsuo Handa wrote:
> I think there are two other problems regarding LSM.
>
> (1) There is only one "struct security_ops" structure in the system.
>
> (2) There is only one "void *security" field in "struct task_struct".
>
>
> Years ago, there was only one MAC implementation (i.e. SELinux)
> in the mainline kernel.
> But now, there are many MAC (or access control/tracking) implementations
> waiting for inclusion into the mainline kernel.
> The competition for occupying "struct security_ops" has started.
>
> My idea is that, why not create chains of "struct security_ops"
> (i.e. linked list of "struct security_ops")
> and allow choosing which chain to use for per a "struct task_struct" basis
> (i.e. add "struct security_ops" to "struct task_struct").
>   
That idea was in the Stacker module, and it was tabled until there is
more than one upstream LSM. In particular, it requires 2 or more LSMs
that actually make sense to stack together. IMHO TOMOYO/AppArmor/SELinux
are all exclusive of one another (in a running kernel) and real stacking
is still pending useful component intrusion prevention modules. Such
modules can be built, they just have not yet been built.

> TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
> "struct security_ops" since SELinux is occupying it.
>   
Just disable SELinux and load TOMOYO. Oh, you can't because someone has
made modules not be loadable :(  Hmmm, perhaps someone could fix that by
reverting the static interface patch ... :)

> May be we should consider stackable LSM again?
>   
Exactly. Stacker was shelved, so to speak :) because of the lack of
in-kernel modules. Soon it will be time to reconsider that.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Tetsuo Handa wrote:
 I think there are two other problems regarding LSM.

 (1) There is only one struct security_ops structure in the system.

 (2) There is only one void *security field in struct task_struct.


 Years ago, there was only one MAC implementation (i.e. SELinux)
 in the mainline kernel.
 But now, there are many MAC (or access control/tracking) implementations
 waiting for inclusion into the mainline kernel.
 The competition for occupying struct security_ops has started.

 My idea is that, why not create chains of struct security_ops
 (i.e. linked list of struct security_ops)
 and allow choosing which chain to use for per a struct task_struct basis
 (i.e. add struct security_ops to struct task_struct).
   
That idea was in the Stacker module, and it was tabled until there is
more than one upstream LSM. In particular, it requires 2 or more LSMs
that actually make sense to stack together. IMHO TOMOYO/AppArmor/SELinux
are all exclusive of one another (in a running kernel) and real stacking
is still pending useful component intrusion prevention modules. Such
modules can be built, they just have not yet been built.

 TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
 struct security_ops since SELinux is occupying it.
   
Just disable SELinux and load TOMOYO. Oh, you can't because someone has
made modules not be loadable :(  Hmmm, perhaps someone could fix that by
reverting the static interface patch ... :)

 May be we should consider stackable LSM again?
   
Exactly. Stacker was shelved, so to speak :) because of the lack of
in-kernel modules. Soon it will be time to reconsider that.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Andrew Morgan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Dolding wrote:
 On 11/1/07, Casey Schaufler [EMAIL PROTECTED] wrote:
 --- Peter Dolding [EMAIL PROTECTED] wrote:
 Posix capabilities predate SELinux. SELinux is not interested in
 Posix capabilities.

 But no IBM had to do it.
 Err, no. It was done by Andrew Morgan back in the dark ages.
 Why on earth do you think IBM did it?
 
 Posix file capabilities the option to replace SUID bit with something
 more security safe only handing out segments of root power instead of
 the complete box and dice like SUID.  Even different on a user by user
 base.
 
 Posix capabilites is what Posix file capabilities is based on.  Yes I
 know the words appear close.  The word file is important.  Please read
 Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html

For the record, I think you are both right. I took a stab at it back
when Casey and I first met:

ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.4-fcap/README

all that stuff worked fine it was just a bit ahead of its time...

- From memory, at that point in time extended attributes were an
external patch, and having some trouble getting merged. My sense was
that EA was a pre-requisite and I was happy to wait for that support to
become integrated before pushing my file capability support.

In the midst of all this LSM emerged as a reaction to Linus' clear
unhappiness about all extensions security. I didn't have the time to
participate in the LSM, and my work sat in the form of these patches.

SELinux at that time existed as a separate infrastructure, and evidently
did have the time to embrace LSM.

 IBM coders worked and got it into the main line really recently to
 provide at least some way to avoid fault of SUID of course it could

[...]

So, yes, IBM (Serge) deserve full credit for starting over, and getting
it merged...

Cheers

Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFHLr6EQheEq9QabfIRAsOrAJ9XzTL0Lqm5jaxwO6UoPB9Pwh3SzQCfVWFd
cPyjsGp/s6D6HuBE6M4NJH0=
=G/ah
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 11/1/07, David Newall <[EMAIL PROTECTED]> wrote:
> Jan Engelhardt wrote:
> > On Nov 1 2007 12:51, Peter Dolding wrote:
> >
> >> This is above me doing code.   No matter how many fixes I do to the
> >> core that will not fix dysfunction in the LSM section.  Strict
> >> policies on fixing the main security model will be required.
> >>
> >
> > If there is no one wanting to fix the existing code, then the
> > perceived problem is not a problem.
>
> What an absurd claim.
>
I agree.  If they can provide a reason.  A correct reason why its not
being fixed then the perceived problem does not exist.  Until then it
common human flaw Tunnel vision.  People normally don't look at the
big picture.

Common fake reason is that Linus does not approve.   History of
patches completely disagrees with that.  Parts Linus has blocked have
been out of alignment with the build into kernel security model.  Yet
other parts that were in alignment with the model have got in during
the same time.  Perfect example of dysfunction making up a lie because
things will not go into kernel exactly how they want.

LSM is nothing more than a testing and model zone.   A place were
important features should not be.  It was put there because model
designs could not get along.   Did that mean that LSM was were the
features were intended to stay.  No the goal should be simple to get
as many good features into the main line as possible while staying in
alignment with the main kernels model.  I don't know where the wrong
idea that the main line did not have a security model came from
either.  Something does not have to be a LSM to be a security model.

XEN, KVM and lguest are not a suitable workaround to problem.  Its
more of LSM developers trying to say its not needed so don't have to
work with each other.  I am not always using x86 machines so at times
not one of those solutions fit.

Containers in Linux kernel get to be processor neutral in features.
So it will not matter what the processor chip it will work.  So the
correct solution to running many LSM somehow has to be done with
Containers.

Note calling me a know it all is not an answer either.   Either they
can put have a good explanation for there failing or the need asses
kicked.  Heck if I am wrong I need ass kick and perfectly prepared to
accept it.  The problem is I am not a person to accept invalid answers
what they have been giving me so far.

My main base is System Administration.  Not coding please note that
System Administrators are the final clients.  If you want someone with
System Administration back ground to take up the leadership of LSM and
bash it into a System Administrator friendly shape I am more than
prepared to do so.  I can bet a System Administrator in charge who is
looking from flexibility's and security point of view is going to get
noses really badly out of joint.  The flexibility bit is currently
missing.   Its not always possible to reboot a server just because the
security framework is not up to the job or client wants you to use a
tighter model.

Yes so people trying to lie to me is something I have very little
tolerance with.  Paperwork like PHD don't scare me off.  I have had to
repair networks destroyed by people with PHD with masters in computer
programming because they run a BIOS destroying virus from a outside
source.  So lets just say my trust has to be earned and using
incorrect facts don't get trust from me.

There is a bigger one than just Containers.  Its called linux on
desktop.   Some how security models will have to tolerate being
controlled from a central server.  Preferred 1 model so any number of
Linux Distros can be used in a network.  Just like different versions
of windows can now.  So somehow we have to get to one master model.
Even if the other models are just like feature tweaks.  Application
controlled allows pam and ldap into play.

Selinux jamed in does not really suit what is needed.  The world of
Linux is changing the LSM need to get there but into gear and catch
up.

Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 11/1/07, David Newall [EMAIL PROTECTED] wrote:
 Jan Engelhardt wrote:
  On Nov 1 2007 12:51, Peter Dolding wrote:
 
  This is above me doing code.   No matter how many fixes I do to the
  core that will not fix dysfunction in the LSM section.  Strict
  policies on fixing the main security model will be required.
 
 
  If there is no one wanting to fix the existing code, then the
  perceived problem is not a problem.

 What an absurd claim.

I agree.  If they can provide a reason.  A correct reason why its not
being fixed then the perceived problem does not exist.  Until then it
common human flaw Tunnel vision.  People normally don't look at the
big picture.

Common fake reason is that Linus does not approve.   History of
patches completely disagrees with that.  Parts Linus has blocked have
been out of alignment with the build into kernel security model.  Yet
other parts that were in alignment with the model have got in during
the same time.  Perfect example of dysfunction making up a lie because
things will not go into kernel exactly how they want.

LSM is nothing more than a testing and model zone.   A place were
important features should not be.  It was put there because model
designs could not get along.   Did that mean that LSM was were the
features were intended to stay.  No the goal should be simple to get
as many good features into the main line as possible while staying in
alignment with the main kernels model.  I don't know where the wrong
idea that the main line did not have a security model came from
either.  Something does not have to be a LSM to be a security model.

XEN, KVM and lguest are not a suitable workaround to problem.  Its
more of LSM developers trying to say its not needed so don't have to
work with each other.  I am not always using x86 machines so at times
not one of those solutions fit.

Containers in Linux kernel get to be processor neutral in features.
So it will not matter what the processor chip it will work.  So the
correct solution to running many LSM somehow has to be done with
Containers.

Note calling me a know it all is not an answer either.   Either they
can put have a good explanation for there failing or the need asses
kicked.  Heck if I am wrong I need ass kick and perfectly prepared to
accept it.  The problem is I am not a person to accept invalid answers
what they have been giving me so far.

My main base is System Administration.  Not coding please note that
System Administrators are the final clients.  If you want someone with
System Administration back ground to take up the leadership of LSM and
bash it into a System Administrator friendly shape I am more than
prepared to do so.  I can bet a System Administrator in charge who is
looking from flexibility's and security point of view is going to get
noses really badly out of joint.  The flexibility bit is currently
missing.   Its not always possible to reboot a server just because the
security framework is not up to the job or client wants you to use a
tighter model.

Yes so people trying to lie to me is something I have very little
tolerance with.  Paperwork like PHD don't scare me off.  I have had to
repair networks destroyed by people with PHD with masters in computer
programming because they run a BIOS destroying virus from a outside
source.  So lets just say my trust has to be earned and using
incorrect facts don't get trust from me.

There is a bigger one than just Containers.  Its called linux on
desktop.   Some how security models will have to tolerate being
controlled from a central server.  Preferred 1 model so any number of
Linux Distros can be used in a network.  Just like different versions
of windows can now.  So somehow we have to get to one master model.
Even if the other models are just like feature tweaks.  Application
controlled allows pam and ldap into play.

Selinux jamed in does not really suit what is needed.  The world of
Linux is changing the LSM need to get there but into gear and catch
up.

Peter Dolding
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Newall]

Jan Engelhardt wrote:

On Nov 1 2007 12:51, Peter Dolding wrote:
  

This is above me doing code.   No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section.  Strict
policies on fixing the main security model will be required.



If there is no one wanting to fix the existing code, then the
perceived problem is not a problem.


What an absurd claim.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

On Nov 1 2007 12:51, Peter Dolding wrote:
>
>This is above me doing code.   No matter how many fixes I do to the
>core that will not fix dysfunction in the LSM section.  Strict
>policies on fixing the main security model will be required.

If there is no one wanting to fix the existing code, then the
perceived problem is not a problem.

Or to put it another way:
"You talk the talk, but do you also walk the walk?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

On Nov 1 2007 12:51, Peter Dolding wrote:

This is above me doing code.   No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section.  Strict
policies on fixing the main security model will be required.

If there is no one wanting to fix the existing code, then the
perceived problem is not a problem.

Or to put it another way:
You talk the talk, but do you also walk the walk?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Newall]

Jan Engelhardt wrote:

On Nov 1 2007 12:51, Peter Dolding wrote:
  

This is above me doing code.   No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section.  Strict
policies on fixing the main security model will be required.



If there is no one wanting to fix the existing code, then the
perceived problem is not a problem.


What an absurd claim.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 11/1/07, Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> --- Peter Dolding <[EMAIL PROTECTED]> wrote:
>
>
> > Improvements to the single security framework are getting over looked.
>
> Please post proposed patches.
>
> >   I would have personally though selinux would have done Posix file
> > capabilities as a general service to all.
>
> Posix capabilities predate SELinux. SELinux is not interested in
> Posix capabilities.
>
> > But no IBM had to do it.
>
> Err, no. It was done by Andrew Morgan back in the dark ages.
> Why on earth do you think IBM did it?


Posix file capabilities the option to replace SUID bit with something
more security safe only handing out segments of root power instead of
the complete box and dice like SUID.  Even different on a user by user
base.

Posix capabilites is what Posix file capabilities is based on.  Yes I
know the words appear close.  The word file is important.  Please read
Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html

IBM coders worked and got it into the main line really recently to
provide at least some way to avoid fault of SUID of course it could
still be made better.  I would have though being a important problem
that other LSM guys would have done it first.  So door to add new
features to kernel is open past any question.  Of course the features
have to be for everyones good.

Andrew Morgan Posix capabilities is something far older its been there
for ages pre selinux the correct fix to SUID for everyone has always
been there by extending Andrew Morgan's work.  So I will ask again why
did IBM have to do Posix file capabilities instead of Selinux.
Selinux has had 7+ years to do it.

Thank you for proving my point past question Casey Schaufler.  You
don't have a single clue of the alterations happing to the main
security model so there is every chance you will overlap with it.

Please get you tech right.  How many other holes are sitting open
because you patch them at LSM level and don't look down into default
security system to see if it should be fixed there.

>
> OK, you have all the answers. Show us some code or STFU.

That is no explanation to why the default security frame work is being
neglected.  I don't have all the answers.  It does not take a person
that high so see that LSM is a screwup leading to people being out of
touch with the main security model and its neglect.  It should not be
requiring outside parties to fix things that in the main security
model.  Only way that can be happening is if LSM is dysfunctional.  7+
year fault at min is not what you can call someone fixing a new fault.
 Now how are we going to fix the mess of LSM's to work correctly for
the good of linux.

One way is appoint one hard minded maintainer that is above my rights.

This is above me doing code.   No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section.  Strict
policies on fixing the main security model will be required.

Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Casey Schaufler]

--- Peter Dolding <[EMAIL PROTECTED]> wrote:


> Improvements to the single security framework are getting over looked.

Please post proposed patches.

>   I would have personally though selinux would have done Posix file
> capabilities as a general service to all.

Posix capabilities predate SELinux. SELinux is not interested in
Posix capabilities. 

> But no IBM had to do it.

Err, no. It was done by Andrew Morgan back in the dark ages.
Why on earth do you think IBM did it?

> ...

OK, you have all the answers. Show us some code or STFU.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

The Clear and Important thing is there is already a single security framework.

The single security framework is the security that exists when no LSM
is loaded.  It turns out the more I look most of my model already
exists just not being used effectively.  There is a capabilities frame
work at worse needs expanding to handling more detailed controls.
Like X thread can only read x y z files an write to a file.

Improvements to the single security framework are getting over looked.
  I would have personally though selinux would have done Posix file
capabilities as a general service to all.  But no IBM had to do it.
This shows a problem.  Critical upgrades to the single security
framework are not being made by LSM producers.  This means one thing
LSM producers are putting there framework before the good of everyone.
  This just cannot keep on going its a path to more and more forks and
more confusion.

Is it Linus getting in way I think not.   Because upgrades are making
it.  Slowly making it but they are making it.   Is it LSM makers
trying to alter the single security framework to there model.  I am
almost perfectly sure that is the main problem.  Next problem is LSM
vs LSM one up man ship ie mine is better than yours or Mine can do all
yours can with 12 times more complex config file.  Not taken a
complete look to see if both sides have advantages.

Part the problem is if you upgrade the single security framework
enough selinux apparmor... most of the LSM will become side shows of
very little importance to security more a s backup to the main
security.  Focus may move back to the old unix locations.  PAM for
creating users and assigning rights and application controlled
security.

Key thing to put  features into the existing single security framework
is flexibility and application control.  Application controlled
security can always beat selinux apparmor and every other LSM I have
ever seen.  The most advanced design of security just happens to the
one you cannot remove.   It also happens to be the most neglected.
The weaknesses that exist in the single security framework is lack of
advancement and repair.

What I class as features is like a fix to a small part.  Ie SUID too
powerful fine grained controls required.
Disk access control methods for file systems without using the
permission system. << Apparmor and relegated path base back end
engine. This also partly allows applications to protect there own
internal users from each other without needing to create system wide
users.  Basically in time internal application users should be equally
protected from each other as system wide users.  This enhancement goes
far past the common day scope of apparmor.  This is the advantage of
taking it out of LSM or at least looking to.  You may see where it can
be make 1000 times more useful as feature than a LSM and provide many
more times system protection even in ways a LSM never could.  Yes
altered apparmor could be really sell able as a core feature.

There are a lot of parts in LSMs that can be broken down into single
feature enhancements.  Major difference is how these features are
controlled.   Applications must be able to directly lower access on a
thread by thread base.  Never raise it.  These features are also
provided to all users on the system to control always even if they
cannot use them due to lack of rights.

Explain to me how its not bitrot leaving the key security framework
without features and then dividing up those features between different
incompatible parts.  This is the basic define of bitrot because you
are making a bigger and bigger mess.

Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Toshiharu Harada]

2007/10/31, Crispin Cowan <[EMAIL PROTECTED]>:
> Peter Dolding wrote:
> > Lets end the bitrot.  Start having bits go into the main OS security
> > features where they should be.
> >
> Linus categorically rejected this idea, several times, very clearly.
>
> He did so because the security community cannot agree on a
> one-true-standard for what that OS security feature set should be. From
> looking at this thread and many others, he is correct; there is no
> consensus on what the feature set should be.
>
> So you can wish for the "main OS security features" all you want, but it
> is not going to happen without a miraculous degree of consensus abruptly
> arising.
>
> On the contrary, security, done well, is a tight fitting suit. It must
> be tight, or it allows too much slack and attackers can exploit that. To
> make it tight, it must be tailored to the situation at hand. That means
> that there may *never* be a consensus on the "one true way", because it
> could be that there is no "one true way". It could be that SMACK is best
> in some cases, AppArmor in others, SELinux in others yet again, MLS in
> others, etc. etc.
>
> I agree with Casey; LSM may not be perfect, but it is a great deal more
> consensus than I have seen anywhere else in the security community. Your
> desire that AppArmor and SELinux should share code has already happened:
> LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and
> TOMOYO, and MultiADM, etc.

My main concern is whether we (different attempts) can share the code.
IOW whether we can reach and form the agreement for single security framework.
It is possible to write code if only we have a clear specifications, but
this is not the case.
I can easily think of LSM, or whatever we call,  as Greatest Common Factor,
but in that case LSM will explode soon and no single module can not be happy,
Linux security will not be achieved.

> It certainly can be improved, but it is not in need of wholesale
> replacement, and especially not without a clear design that addresses
> clearly stated problems that lots of people are having.

We should not invent wheels, that is agreed by everyone , but if we try to share
something that we can not share, we will fail. From the fact existing
LSM did not satisfy any module (including SELinux), I do not
want to investigate stack able version.

Cheers,
Toshiharu Harada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 10/31/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Peter Dolding wrote:
> > Lets end the bitrot.  Start having bits go into the main OS security
> > features where they should be.
> >
> Linus categorically rejected this idea, several times, very clearly.
>
> He did so because the security community cannot agree on a
> one-true-standard for what that OS security feature set should be. From
> looking at this thread and many others, he is correct; there is no
> consensus on what the feature set should be.
>
> So you can wish for the "main OS security features" all you want, but it
> is not going to happen without a miraculous degree of consensus abruptly
> arising.
>
Not really.  Every time Linus has rejected is when people have tried
to thump complete models like Selinux into kernel as one huge mother
of a blocks without grounds.

MultiAdmin is different most other models.  Please look at Posix File
Capabilities.  Grounds and security advantages of that module was
proven while not fighting with other LSM means to do protection.
There are grounds for many admins in linux for tracking admin
alterations.  It falls into a cat of a feature request and security
feature.  Of course not all of MultiAdmin features will be suitable at
main OS security features.  Yes MultiAdmin will have to be happy to
break there code up to get the as there key feature to as many users
as able.  This is a difference UID 0 all powerful I guess everyone
here can agree that is not exactly good.  Not being able to trace who
did alterations as UID 0 is not good either.  Where does the other
frameworks deal with it.

The path is still open into kernel.  Complete models of course are
never going to make it.  100 percent consensus is not always required.
 Same reasons for Posix File Capabilities providing a segmented SUID
feature.  Applying the same Capabilities on a user by user base also
has equal advantages instead of having UID 0 or not UID 0.

Next important question why not look at segments to put forward
consensus.  This is something is not clearly being looked for.

100 percent consensus has never been true for every feature in Linux.

>On the contrary, security, done well, is a tight fitting suit. It must
>be tight, or it allows too much slack and attackers can exploit that.

I love that quote.  There is difference to tight fitting and covering
everything needed.  Ie tight fitting suit without pockets is going to
be a pain.

Main OS security features always made tight by the LSM.  Since they
are override able.

This can solve the stack problem to a point.   Of course not a perfect solution.

Chain passing threw LSM is not a solution.  Never will be.  A
applications on systems may require many different security models to
protect them.

Needing hooks everywhere with unlimited control provided at a single
interface does not look like a tight security model to me.  Makes LSM
look like the Ideal rootkit location.

LSM bundling hooks into security interfaces segments and reduces
threat.  Since each interface has rules and limitations.

Of course my ideas have not been fully documented out correct.   I am
not foolish my skills are not perfect.  The reason behind my ideas is
to get past the limitations of LSM.

The differences between LSMs get less different the closer you get to
the LSM interface.

Label vs path based is the biggest divide.   Including the config
system of modules makes merging hard.  Catch is Label and path based
both have there places.  Ie filesystem limitations(path based) and
speed(label based).  So both being side by side in the kernel I have
no issue with.  I really have to ask why selinux does not support path
based for the odd file systems that don't support labels and the
reverse with apparmor?  Is it that the developers have been building a
empire and not see the need for the others features so failing
completely to build the most powerful security framework.

Yes LSM is only a testing ground and for features that no everyone
wants.  ie Not everyone wants selinux apparmor... Models.  For things
like posix file capabilities its just a testing ground for features
before it moved into kernel full time.

LSM has two uses. Not one.

'one true security model' I am not talking about that with Multiadmin
main goal is a Security Feature it really does not make up a complete
model in its own right.  Different Admins with different capability's.
 Now the final form of Multiadmin who knows.  If we had file access
controls at the same level of control as posix file capabilities there
is a chance that Multiadmin core features could be done threw pam.
Lack of core features is forcing things into the LSM level that may
not need to be there.  Having users with permissions more limited to
filesystem would be useful.  There are small fragments of LSM that
have uses out side the LSM framework also what you are failing to
offer.

This is the problem with Multiadmin its existence is truly
questionable.   Why does it exist where 

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

[Peter Dolding]

On 10/31/07, Crispin Cowan [EMAIL PROTECTED] wrote:
 Peter Dolding wrote:
  Lets end the bitrot.  Start having bits go into the main OS security
  features where they should be.
 
 Linus categorically rejected this idea, several times, very clearly.

 He did so because the security community cannot agree on a
 one-true-standard for what that OS security feature set should be. From
 looking at this thread and many others, he is correct; there is no
 consensus on what the feature set should be.

 So you can wish for the main OS security features all you want, but it
 is not going to happen without a miraculous degree of consensus abruptly
 arising.

Not really.  Every time Linus has rejected is when people have tried
to thump complete models like Selinux into kernel as one huge mother
of a blocks without grounds.

MultiAdmin is different most other models.  Please look at Posix File
Capabilities.  Grounds and security advantages of that module was
proven while not fighting with other LSM means to do protection.
There are grounds for many admins in linux for tracking admin
alterations.  It falls into a cat of a feature request and security
feature.  Of course not all of MultiAdmin features will be suitable at
main OS security features.  Yes MultiAdmin will have to be happy to
break there code up to get the as there key feature to as many users
as able.  This is a difference UID 0 all powerful I guess everyone
here can agree that is not exactly good.  Not being able to trace who
did alterations as UID 0 is not good either.  Where does the other
frameworks deal with it.

The path is still open into kernel.  Complete models of course are
never going to make it.  100 percent consensus is not always required.
 Same reasons for Posix File Capabilities providing a segmented SUID
feature.  Applying the same Capabilities on a user by user base also
has equal advantages instead of having UID 0 or not UID 0.

Next important question why not look at segments to put forward
consensus.  This is something is not clearly being looked for.

100 percent consensus has never been true for every feature in Linux.

On the contrary, security, done well, is a tight fitting suit. It must
be tight, or it allows too much slack and attackers can exploit that.

I love that quote.  There is difference to tight fitting and covering
everything needed.  Ie tight fitting suit without pockets is going to
be a pain.

Main OS security features always made tight by the LSM.  Since they
are override able.

This can solve the stack problem to a point.   Of course not a perfect solution.

Chain passing threw LSM is not a solution.  Never will be.  A
applications on systems may require many different security models to
protect them.

Needing hooks everywhere with unlimited control provided at a single
interface does not look like a tight security model to me.  Makes LSM
look like the Ideal rootkit location.

LSM bundling hooks into security interfaces segments and reduces
threat.  Since each interface has rules and limitations.

Of course my ideas have not been fully documented out correct.   I am
not foolish my skills are not perfect.  The reason behind my ideas is
to get past the limitations of LSM.

The differences between LSMs get less different the closer you get to
the LSM interface.

Label vs path based is the biggest divide.   Including the config
system of modules makes merging hard.  Catch is Label and path based
both have there places.  Ie filesystem limitations(path based) and
speed(label based).  So both being side by side in the kernel I have
no issue with.  I really have to ask why selinux does not support path
based for the odd file systems that don't support labels and the
reverse with apparmor?  Is it that the developers have been building a
empire and not see the need for the others features so failing
completely to build the most powerful security framework.

Yes LSM is only a testing ground and for features that no everyone
wants.  ie Not everyone wants selinux apparmor... Models.  For things
like posix file capabilities its just a testing ground for features
before it moved into kernel full time.

LSM has two uses. Not one.

'one true security model' I am not talking about that with Multiadmin
main goal is a Security Feature it really does not make up a complete
model in its own right.  Different Admins with different capability's.
 Now the final form of Multiadmin who knows.  If we had file access
controls at the same level of control as posix file capabilities there
is a chance that Multiadmin core features could be done threw pam.
Lack of core features is forcing things into the LSM level that may
not need to be there.  Having users with permissions more limited to
filesystem would be useful.  There are small fragments of LSM that
have uses out side the LSM framework also what you are failing to
offer.

This is the problem with Multiadmin its existence is truly
questionable.   Why does it exist where it does.  Even why it 

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

[Toshiharu Harada]

2007/10/31, Crispin Cowan [EMAIL PROTECTED]:
 Peter Dolding wrote:
  Lets end the bitrot.  Start having bits go into the main OS security
  features where they should be.
 
 Linus categorically rejected this idea, several times, very clearly.

 He did so because the security community cannot agree on a
 one-true-standard for what that OS security feature set should be. From
 looking at this thread and many others, he is correct; there is no
 consensus on what the feature set should be.

 So you can wish for the main OS security features all you want, but it
 is not going to happen without a miraculous degree of consensus abruptly
 arising.

 On the contrary, security, done well, is a tight fitting suit. It must
 be tight, or it allows too much slack and attackers can exploit that. To
 make it tight, it must be tailored to the situation at hand. That means
 that there may *never* be a consensus on the one true way, because it
 could be that there is no one true way. It could be that SMACK is best
 in some cases, AppArmor in others, SELinux in others yet again, MLS in
 others, etc. etc.

 I agree with Casey; LSM may not be perfect, but it is a great deal more
 consensus than I have seen anywhere else in the security community. Your
 desire that AppArmor and SELinux should share code has already happened:
 LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and
 TOMOYO, and MultiADM, etc.

My main concern is whether we (different attempts) can share the code.
IOW whether we can reach and form the agreement for single security framework.
It is possible to write code if only we have a clear specifications, but
this is not the case.
I can easily think of LSM, or whatever we call,  as Greatest Common Factor,
but in that case LSM will explode soon and no single module can not be happy,
Linux security will not be achieved.

 It certainly can be improved, but it is not in need of wholesale
 replacement, and especially not without a clear design that addresses
 clearly stated problems that lots of people are having.

We should not invent wheels, that is agreed by everyone , but if we try to share
something that we can not share, we will fail. From the fact existing
LSM did not satisfy any module (including SELinux), I do not
want to investigate stack able version.

Cheers,
Toshiharu Harada
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

The Clear and Important thing is there is already a single security framework.

The single security framework is the security that exists when no LSM
is loaded.  It turns out the more I look most of my model already
exists just not being used effectively.  There is a capabilities frame
work at worse needs expanding to handling more detailed controls.
Like X thread can only read x y z files an write to a file.

Improvements to the single security framework are getting over looked.
  I would have personally though selinux would have done Posix file
capabilities as a general service to all.  But no IBM had to do it.
This shows a problem.  Critical upgrades to the single security
framework are not being made by LSM producers.  This means one thing
LSM producers are putting there framework before the good of everyone.
  This just cannot keep on going its a path to more and more forks and
more confusion.

Is it Linus getting in way I think not.   Because upgrades are making
it.  Slowly making it but they are making it.   Is it LSM makers
trying to alter the single security framework to there model.  I am
almost perfectly sure that is the main problem.  Next problem is LSM
vs LSM one up man ship ie mine is better than yours or Mine can do all
yours can with 12 times more complex config file.  Not taken a
complete look to see if both sides have advantages.

Part the problem is if you upgrade the single security framework
enough selinux apparmor... most of the LSM will become side shows of
very little importance to security more a s backup to the main
security.  Focus may move back to the old unix locations.  PAM for
creating users and assigning rights and application controlled
security.

Key thing to put  features into the existing single security framework
is flexibility and application control.  Application controlled
security can always beat selinux apparmor and every other LSM I have
ever seen.  The most advanced design of security just happens to the
one you cannot remove.   It also happens to be the most neglected.
The weaknesses that exist in the single security framework is lack of
advancement and repair.

What I class as features is like a fix to a small part.  Ie SUID too
powerful fine grained controls required.
Disk access control methods for file systems without using the
permission system.  Apparmor and relegated path base back end
engine. This also partly allows applications to protect there own
internal users from each other without needing to create system wide
users.  Basically in time internal application users should be equally
protected from each other as system wide users.  This enhancement goes
far past the common day scope of apparmor.  This is the advantage of
taking it out of LSM or at least looking to.  You may see where it can
be make 1000 times more useful as feature than a LSM and provide many
more times system protection even in ways a LSM never could.  Yes
altered apparmor could be really sell able as a core feature.

There are a lot of parts in LSMs that can be broken down into single
feature enhancements.  Major difference is how these features are
controlled.   Applications must be able to directly lower access on a
thread by thread base.  Never raise it.  These features are also
provided to all users on the system to control always even if they
cannot use them due to lack of rights.

Explain to me how its not bitrot leaving the key security framework
without features and then dividing up those features between different
incompatible parts.  This is the basic define of bitrot because you
are making a bigger and bigger mess.

Peter Dolding
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Casey Schaufler]

--- Peter Dolding [EMAIL PROTECTED] wrote:


 Improvements to the single security framework are getting over looked.

Please post proposed patches.

   I would have personally though selinux would have done Posix file
 capabilities as a general service to all.

Posix capabilities predate SELinux. SELinux is not interested in
Posix capabilities. 

 But no IBM had to do it.

Err, no. It was done by Andrew Morgan back in the dark ages.
Why on earth do you think IBM did it?

 ...

OK, you have all the answers. Show us some code or STFU.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 11/1/07, Casey Schaufler [EMAIL PROTECTED] wrote:

 --- Peter Dolding [EMAIL PROTECTED] wrote:


  Improvements to the single security framework are getting over looked.

 Please post proposed patches.

I would have personally though selinux would have done Posix file
  capabilities as a general service to all.

 Posix capabilities predate SELinux. SELinux is not interested in
 Posix capabilities.

  But no IBM had to do it.

 Err, no. It was done by Andrew Morgan back in the dark ages.
 Why on earth do you think IBM did it?


Posix file capabilities the option to replace SUID bit with something
more security safe only handing out segments of root power instead of
the complete box and dice like SUID.  Even different on a user by user
base.

Posix capabilites is what Posix file capabilities is based on.  Yes I
know the words appear close.  The word file is important.  Please read
Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html

IBM coders worked and got it into the main line really recently to
provide at least some way to avoid fault of SUID of course it could
still be made better.  I would have though being a important problem
that other LSM guys would have done it first.  So door to add new
features to kernel is open past any question.  Of course the features
have to be for everyones good.

Andrew Morgan Posix capabilities is something far older its been there
for ages pre selinux the correct fix to SUID for everyone has always
been there by extending Andrew Morgan's work.  So I will ask again why
did IBM have to do Posix file capabilities instead of Selinux.
Selinux has had 7+ years to do it.

Thank you for proving my point past question Casey Schaufler.  You
don't have a single clue of the alterations happing to the main
security model so there is every chance you will overlap with it.

Please get you tech right.  How many other holes are sitting open
because you patch them at LSM level and don't look down into default
security system to see if it should be fixed there.


 OK, you have all the answers. Show us some code or STFU.

That is no explanation to why the default security frame work is being
neglected.  I don't have all the answers.  It does not take a person
that high so see that LSM is a screwup leading to people being out of
touch with the main security model and its neglect.  It should not be
requiring outside parties to fix things that in the main security
model.  Only way that can be happening is if LSM is dysfunctional.  7+
year fault at min is not what you can call someone fixing a new fault.
 Now how are we going to fix the mess of LSM's to work correctly for
the good of linux.

One way is appoint one hard minded maintainer that is above my rights.

This is above me doing code.   No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section.  Strict
policies on fixing the main security model will be required.

Peter Dolding
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Peter Dolding wrote:
> Lets end the bitrot.  Start having bits go into the main OS security
> features where they should be.
>   
Linus categorically rejected this idea, several times, very clearly.

He did so because the security community cannot agree on a
one-true-standard for what that OS security feature set should be. From
looking at this thread and many others, he is correct; there is no
consensus on what the feature set should be.

So you can wish for the "main OS security features" all you want, but it
is not going to happen without a miraculous degree of consensus abruptly
arising.

On the contrary, security, done well, is a tight fitting suit. It must
be tight, or it allows too much slack and attackers can exploit that. To
make it tight, it must be tailored to the situation at hand. That means
that there may *never* be a consensus on the "one true way", because it
could be that there is no "one true way". It could be that SMACK is best
in some cases, AppArmor in others, SELinux in others yet again, MLS in
others, etc. etc.

I agree with Casey; LSM may not be perfect, but it is a great deal more
consensus than I have seen anywhere else in the security community. Your
desire that AppArmor and SELinux should share code has already happened:
LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and
TOMOYO, and MultiADM, etc.

It certainly can be improved, but it is not in need of wholesale
replacement, and especially not without a clear design that addresses
clearly stated problems that lots of people are having.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[david]

On Wed, 31 Oct 2007, Peter Dolding wrote:


On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

On Wed, 31 Oct 2007, Peter Dolding wrote:


MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
applied over using Selinux rules.  This is just the way it is stacking LSM's
is Just not healthy you always risk on LSM breaking another.  Part of the
reason why I have suggested a complete redesign of LSM.  To get away from
this problem of stacking.


since the method of stacking hasn't been determined yet, you can't say
this.


I can because that is the current day problem. With many LSM's loaded
they stack completely as a complete mess and with problems.  They
fight with each other.  Lack of define on stacking equals big
problems.   Since you have not created a standard for stacking does
not stop the problem from existing.  Nice lack of planing when LSM
started or maybe its intentional.  When you need stacking its about
time you start moving things into the OS?


the lack of a stacking ability was deliberate (go back and read the 
archives). basicly no LSM was willing to admit that they weren't the 
be-all, end-all of security, so nobody was willing to consider that anyone 
would ever want anything else.


one method of doing the stacking would be for the LSM to not know about 
the stacking, but the kernel takes care of passing all requests through 
each LSM in order (if the LSMs can be staticly compiled the order should 
be able to be changed at compile time)


now, the existing policies for some LSM's may need to change, becouse 
they've been assuming that they only needed to check capabilities for 
UID=0, when they will now need to check them for everyone, but arguably, 
this was a bug masquerading as an optimization in the first place.



There is a way around the problem too without allowing LSM to stack.
Good advantage backward compatible  because your are not playing with
the LSM standard to do it so no LSM modules should need large
alterations.  At worse mirror extensions to handle the new OS feature.
Posix File Capabilities provide the solution.   First done as a LSM
risked conflict.   Moved in as a operating system extension by by
conflict.  Fragments from LSM's should exactly move that way if they
expect to be overlapped by other models.

Lot of stacking problems can be avoided if segments are complete
standard extensions.


which LSM gets to declare the standards?



it would be possible for MultiAdmin to grant additional access, that
SELinux then denies for it's own reasons.

if the SELinux policy is written so that it ignores capabilities, and
instead just looks at uid0 then that policy is broken in a stacked
environment, but it's the polciy that's broken, not the stacking.


That is not how current day always works.  MultiAdmin grants and that
can be the end of the treeing.   Selinux does not get asked if it
refuses it or not.  So no matter what was set in the Selinux policy it
may never get used.   Adding more layers is also bad for performance
to.  Treeing threw modules for rights is a really slow process.  As
like a posix feature extension.   Selinux/Other LSM's is at top of
allocation no flaw no bypass.


only if the stacking mode permits this. if it always requires passing 
through all the layers then this wouldn't be a problem.


Besides which, the MultiAdmin authors would probably be willing to make 
the nessasary changes to their LSM to play nicely with others anyway (but 
good programming practice would dictate that you don't count on it, and 
arrange for the other modules to approve as well)



yes, there will be interactions that don't make sense, but just becouse
something can be used wrong doesn't mean that there aren't other cases
where it can be used properly.


We are talking security here if its not order safe its not good.
MultiAdmin done as a posix feature extension is order safe.
MultiAdmin done as a LSM is not order safe.


as things are currently written, it's not possible to stack, so there is 
no order. change how things are written and you can make them safe.



System Admins are humans too.  Getting orders backwards does happen.
So should be avoided where able.


the sysadmins need to be given enough rope, you don't know everything that 
they are trying to do, and you don't know what other LSMs going to do. so 
how can you possibly decide ahead of time what orders are safe?



This completely avoids the need for adding another layer of stacking
and since built inside current day framework.  Does doing this risk
the end of LSM's as we know it yes it does.  Since it is not being
used as LSM were intended.  LSM is just a addon to standard OS
security what is either a testing ground for new features to secure
the OS that get build into the OS in time or as location for security
modules.

Somethings should be just done in the Standard OS security nothing to
do with LSM.

Little bit hard for some I guess to hear that LSM are not all
important and 

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

[Casey Schaufler]

--- Peter Dolding <[EMAIL PROTECTED]> wrote:


> Lets end the bitrot.  Start having bits go into the main OS security
> features where they should be.

Gawd. Sorry, but we lost that argument in 1986 and the situation
hasn't changed a bit since. Most people just don't want what we're
selling. Do you know why Unix was a success and MULTICS* a failure?
It's because Unix had mode bits and MULTICS had ACLs. Fortunately
for those of us who wear titles like "Security Expert" or "Trust
Technologist" with pride there are enough clinical paranoids in
positions of authority to keep the Trusted System niche from closing
up completely and hence supporting our Rock Star Lifestyles. The
good news is that the situation is no worse than that faced by
the people who are bringing you Infiniband or Itanium, neither of
which will ever be the life of the party either. Sure security is
important, but I learned (in college, and yes they had colleges
way back then) not to drink too much at parties I'd crashed.

LSM isn't all I want it to be either, but it's better than I ever
got in the Proprietary OS world, and that includes when the MLS
systems were bringing in $20million a pop. Trying to force features
that virtually no one wants into any system is a bad idea. If
you haven't read Man of LaMancha I strongly suggest you do so.
Or at least see the play, it's got some catchy songs.

-
* If you don't know what MULTICS was you can buy me a beer and
  I'll tell you the whole story


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Wed, 31 Oct 2007, Peter Dolding wrote:
>
> > MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
> > applied over using Selinux rules.  This is just the way it is stacking LSM's
> > is Just not healthy you always risk on LSM breaking another.  Part of the
> > reason why I have suggested a complete redesign of LSM.  To get away from
> > this problem of stacking.
>
> since the method of stacking hasn't been determined yet, you can't say
> this.

I can because that is the current day problem. With many LSM's loaded
they stack completely as a complete mess and with problems.  They
fight with each other.  Lack of define on stacking equals big
problems.   Since you have not created a standard for stacking does
not stop the problem from existing.  Nice lack of planing when LSM
started or maybe its intentional.  When you need stacking its about
time you start moving things into the OS?

There is a way around the problem too without allowing LSM to stack.
Good advantage backward compatible  because your are not playing with
the LSM standard to do it so no LSM modules should need large
alterations.  At worse mirror extensions to handle the new OS feature.
 Posix File Capabilities provide the solution.   First done as a LSM
risked conflict.   Moved in as a operating system extension by by
conflict.  Fragments from LSM's should exactly move that way if they
expect to be overlapped by other models.

Lot of stacking problems can be avoided if segments are complete
standard extensions.
>
> it would be possible for MultiAdmin to grant additional access, that
> SELinux then denies for it's own reasons.
>
> if the SELinux policy is written so that it ignores capabilities, and
> instead just looks at uid0 then that policy is broken in a stacked
> environment, but it's the polciy that's broken, not the stacking.

That is not how current day always works.  MultiAdmin grants and that
can be the end of the treeing.   Selinux does not get asked if it
refuses it or not.  So no matter what was set in the Selinux policy it
may never get used.   Adding more layers is also bad for performance
to.  Treeing threw modules for rights is a really slow process.  As
like a posix feature extension.   Selinux/Other LSM's is at top of
allocation no flaw no bypass.

> yes, there will be interactions that don't make sense, but just becouse
> something can be used wrong doesn't mean that there aren't other cases
> where it can be used properly.
>
We are talking security here if its not order safe its not good.
MultiAdmin done as a posix feature extension is order safe.
MultiAdmin done as a LSM is not order safe.

System Admins are humans too.  Getting orders backwards does happen.
So should be avoided where able.

This completely avoids the need for adding another layer of stacking
and since built inside current day framework.  Does doing this risk
the end of LSM's as we know it yes it does.  Since it is not being
used as LSM were intended.  LSM is just a addon to standard OS
security what is either a testing ground for new features to secure
the OS that get build into the OS in time or as location for security
modules.

Somethings should be just done in the Standard OS security nothing to
do with LSM.

Little bit hard for some I guess to hear that LSM are not all
important and not all Security features should be done in them.  Some
should be done in the main OS security features.

Biggest current day problem with LSM is they have forgot that LSM is
only a testing ground or a zone for features that people will only
want some of the time.

MultiAdmin is a feature that can enhance means to Audit OS ie who did
what.  Enhance security hand outs and can be really handy with almost
any LSM on the system.  Its description of what it is sounds very much
like every other standard feature.

Lets end the bitrot.  Start having bits go into the main OS security
features where they should be.

Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[david]

On Wed, 31 Oct 2007, Peter Dolding wrote:

MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are 
applied over using Selinux rules.  This is just the way it is stacking LSM's 
is Just not healthy you always risk on LSM breaking another.  Part of the 
reason why I have suggested a complete redesign of LSM.  To get away from 
this problem of stacking.


since the method of stacking hasn't been determined yet, you can't say 
this.


it would be possible for MultiAdmin to grant additional access, that 
SELinux then denies for it's own reasons.


if the SELinux policy is written so that it ignores capabilities, and 
instead just looks at uid0 then that policy is broken in a stacked 
environment, but it's the polciy that's broken, not the stacking.


yes, there will be interactions that don't make sense, but just becouse 
something can be used wrong doesn't mean that there aren't other cases 
where it can be used properly.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

Jan Engelhardt wrote:

I disagree.

Traditionally, Linux has given a process all capabilities when the
UID changed to 0 (either by setuid(2) or executing a SUID binary).
This has been relieved over the years, and right now with LSMs in the
field, it is possible to 'deactivate' this special case for UID 0.
  
SELinux does not have this special case for UID 0. Neither does it

seem to use capabilities (quick grep through the source). So
basically, all users are the same, and no one has capabilities by
default. Does SELinux thus break with other LSMs?

Now assume a SELinux system where all users have all capabilities
(and the policy that is in place restricts the use of these
capabilities then) -- should not be that unlikely. Does that break
with other LSMs?
  
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules 
are applied over using Selinux rules.  This is just the way it is 
stacking LSM's is Just not healthy you always risk on LSM breaking 
another.  Part of the reason why I have suggested a complete redesign of 
LSM.  To get away from this problem of stacking.


I see MultiAdmin purely in the class of posix file capabilities( Fine 
grained replacement to SUID).
This is a standard feature fix not part of LSM.  Note it can not replace 
all SUID bits due to some internals of applications design need to be 
changed to support posix file capabilities in particular not checking if 
running as UID 0.  Traditional  UID 0 is already optional for 
applications without  LSM's.


Posix file capabilities only applies to applications only.  MultiAdmin 
being the user mirror of Posix file capabilities.


MultiAdmin patch to the user side may allow more SUID bits to be killed 
off from the start line.  So increasing overall system security.


Of course MultiAdmin might end up two halfs.   One a standard feature 
that hands out capabilities to users that LSMs can overrule.  And one a 
user by user directory access control LSM directory control LSM less 
likely to cause problems.


I really don't see the need for a LSM stacking order.  Some features 
just should not be LSM's in my eyes.  MultiAdmin is one of them.


Traditional way has all ready been expanded for applications without 
LSM's.  So my call still stand O heck head ache rating.   Because its in 
the wrong place.  Particularly when you think people will want to use it 
stacked with other LSM's.   Stacking should be avoided where able.   
This means at least some of Multiadmin features just have to be done 
core kernel as a normal kernel module to avoid stacking and breaking the 
LSM.


Note posix file capabilities was developed as a LSM module too at first 
the point came where it was going to cause more trouble for other LSMs 
granting stuff in conflict.Both Multiadmin and posix file 
capabilities share a lot in common.  Both developed in the wrong place.  
Both required to be else where.  Even there function is similar breaking 
down root powers and handing them out more effectively.  So in my eyes 
it is a pure Posix extension not a LSM.


Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

On Oct 30 2007 12:14, Casey Schaufler wrote:
>
>while others including SELinux will go their own ways. So long
>as LSMs are self contained and strictly restrictive the
>mechanisms they use to modulate their behavior shouldn't be an
>issue. If SELinux chooses to turn its MLS controls off between
>midnight and 3am I can't see how that would be Smack's business,
>even if they were somehow stacked. Multiple LSMs has issues,
>like what should security_secid_to_secctx() return to the audit
>system, but privilege model shouldn't be one of them.

I am with you on that. And for everybody who missed it: MultiAdmin
only grants rights at the same time commoncap does (e.g. on setuid
and bprm_set_security). And all modules DO work with commoncap, now
don't they?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Casey Schaufler]

--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:

> 
> (please do not drop Cc, or I would have lost this thread part if I had 
> not been on lkml. And sometimes I am not because of the volume. Thanks.)
> 
> On Oct 30 2007 15:13, Peter Dolding wrote:
> >On 10/30/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> >
> >> * I have no clue what family to put MultiADM or Dazuko into
> >
> >MultiADMIN falls under o my god head ache.  This is more a posix
> >standard feature altered ie 1 root user turned into many.  This really
> >risks breaking the other models as a LSM.
> 
> I disagree.
> 
> Traditionally, Linux has given a process all capabilities when the
> UID changed to 0 (either by setuid(2) or executing a SUID binary).
> This has been relieved over the years, and right now with LSMs in the
> field, it is possible to 'deactivate' this special case for UID 0.
> 
> SELinux does not have this special case for UID 0. Neither does it
> seem to use capabilities (quick grep through the source). So
> basically, all users are the same, and no one has capabilities by
> default. Does SELinux thus break with other LSMs?
> 
> Now assume a SELinux system where all users have all capabilities
> (and the policy that is in place restricts the use of these
> capabilities then) -- should not be that unlikely. Does that break
> with other LSMs?

As some of the early Smack discussions brought out, some LSMs
including Smack will be perfectly happy with the traditional
Linux privilege mechanisms (choice of root and/or capablities)
while others including SELinux will go their own ways. So long
as LSMs are self contained and strictly restrictive the
mechanisms they use to modulate their behavior shouldn't be an
issue. If SELinux chooses to turn its MLS controls off between
midnight and 3am I can't see how that would be Smack's business,
even if they were somehow stacked. Multiple LSMs has issues,
like what should security_secid_to_secctx() return to the audit
system, but privilege model shouldn't be one of them.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

(please do not drop Cc, or I would have lost this thread part if I had 
not been on lkml. And sometimes I am not because of the volume. Thanks.)

On Oct 30 2007 15:13, Peter Dolding wrote:
>On 10/30/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
>
>> * I have no clue what family to put MultiADM or Dazuko into
>
>MultiADMIN falls under o my god head ache.  This is more a posix
>standard feature altered ie 1 root user turned into many.  This really
>risks breaking the other models as a LSM.

I disagree.

Traditionally, Linux has given a process all capabilities when the
UID changed to 0 (either by setuid(2) or executing a SUID binary).
This has been relieved over the years, and right now with LSMs in the
field, it is possible to 'deactivate' this special case for UID 0.

SELinux does not have this special case for UID 0. Neither does it
seem to use capabilities (quick grep through the source). So
basically, all users are the same, and no one has capabilities by
default. Does SELinux thus break with other LSMs?

Now assume a SELinux system where all users have all capabilities
(and the policy that is in place restricts the use of these
capabilities then) -- should not be that unlikely. Does that break
with other LSMs?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Bernd Petrovitsch]

On Thu, 2007-10-25 at 09:04 -0700, Ray Lee wrote:
> On 10/25/07, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> > On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
> > []
> > > Key-based masterlocks are easily broken with freon, and their combo
> > > locks are easily brute-forced in about ten minutes. Yet, I'll still
> > > use them to lock up my bike and garage.
> >
> > The question is what the security threat is and the value of the secured
> > items.
> >
> > > The idea that poor security is worse than no security is fallacious,
> > > and not backed up by common experience.
> >
> > The common experience is, that common people just *feel* safer (just
> > because they have poor security).
> 
> Do you lock your bike up when you leave it lying around? My point is
> that real security comes in layers, not one perfect solution that will
> always work everywhere for everyone. The latter is a pipe-dream.

Of course not. "Security" as such is more than less "only" risk
management (or part of it - depending of the viewpoint).

> > With no security, they know that there is no security. With poor
> > security, they do not know (or can deny) that they have next to no real
> > security.
> 
> The fallacy here is to believe that just because they have no
> security, that it will *in*any*way* change their behavior. I deal with
> real users daily, and *they*don't*care*. Further, there's no level of

If people don't care, they are pretty lost anyway.
That's actually the reason for all that security stuff that no one wants
but which stands in the way of all people just because of the "don't
care" faction (which by far the majority of all in any given area).
But there is that (also not too small) "I installed $PERSONAL_FIREWALL
and *nothing* can happen because $VENDOR and $TECH_JOURNALIST in
$LOW_QUALITY_PC_MAG said so" faction.

> education that we can instill into the community to make them aware of
> the issues and change their habits accordingly, because real users
> don't have the background to understand those lessons.
> 
> While you can teach them that running an executable from someone they
> haven't heard of is obviously bad, they don't know why downloading an
> image is potentially dangerous, "it's an image, right?" "Well, there's
> these things called buffer overflows..." 
> 
> Security is not an all or nothing game, it's layers. And we have to

And every layer/subsystem/area must be checked and seen independently of
others (or the dependency must be that strong that no one can work
around).
And every security layer will and should have it's purpose and targets.

> make sure that the layers are usable without taking a course from the
> NSA. I'd love to see a poll of the kernel development community to
> find out how many use SELinux on their machines, for example.

"selinux=0" on the kernel commandline is normal - no unknown people have
logins and so there was no reason to learn it. And against should it
protect in the first place if only trusted people are there?

> > The prime example here is the usual (so-called) "personal firewall" on
> > Windows where people work normally as "administrator".
> 
> So your argument is that if there weren't a personal firewall on
> Windows, that a significant number of people would then not run as
> Administrator? I beg to differ.

No, how do you come to that conclusion?

People login as "Administrator" because they did it since DOS3.0.
People buy and install $PERSONAL_FIREWALL because some cheap PC tech
magazine had advertisements for them.
Next generation (or this generation?) viruses/malware will either
reconfigure $PERSONAL_FIREWALL silently (and if course only
temporarily).
And the vendor of $PERSONAL_FIREWALL writes into the manual (which no
one reads) or the EULA (which no one reads because it isn't relevant in
the first place) or some README (which no one finds) that one must not
login as "Administrator". But that just to keep the vict^Wbuyers to not
sue them. And working on Win* without being "Administrator" is a real
PITA - so the average user won't do it for long.

So apart from the personal feelings of that user I can't find any sign
of security.

BTW from a commercial viewpoint, the (so-called) "personal firewalls"
were probably one of the best ideas (and another major example that
technical expertise has nothing to do with sales success).

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

On Oct 30 2007 01:50, Crispin Cowan wrote:
>Jan Engelhardt wrote:
>> Apparmor tutorial (beats any FAQ at first):
>>  ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
>>   
>Thanks for the high praise. Unfortunately that FTP site seems to not be
>working. Some alternatives:
[...]

Actually, if the selinux team would do the same [introductionary video],
I'd guess the hardness level commonly associated with selinux could be
relieved a bit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Toshiharu Harada]

On 10/30/2007 5:40 PM, Jan Engelhardt wrote:

On Oct 30 2007 12:23, Toshiharu Harada wrote:

Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in

http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison


Smack Security Model: autolabel, as far as I can tell.

I noticed the smell of danger in the naming of "Security Model".
Please allow me some time.


Smack Policy Generation: user - hand - and an editor
Apparmor tutorial (beats any FAQ at first):
ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi

Updated above two items. Thank you. :)

I'm not an optimist to believe we can reach the perfect
comparison. The purpose is to feed information, not to judge.
This might sound ironically, but I don't really think
we can *compare* them because they have different
theories/purposes/backgrounds. Some kind of forgiveness and
fuzziness are required.

As I don't want to steal everybody's bandwidth,
simple updates will be done silently. Your suggestions and
information will be greatly appreciated despite of
visible evidence.

Thank you.
Toshiharu Harada

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Jan Engelhardt wrote:
> Apparmor tutorial (beats any FAQ at first):
>   ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
>   
Thanks for the high praise. Unfortunately that FTP site seems to not be
working. Some alternatives:

* My personal copy of the above video
  http://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi
* Similar talk at linux.conf.au 2007
  http://youtube.com/watch?v=EgrfmSm0NWs
* Similar talk at Defcon 2007
  http://video.google.com/videoplay?docid=-1731833784646588861=en

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

On Oct 30 2007 12:23, Toshiharu Harada wrote:
>
> Instead of pushing TOMOYO Linux, I started developing
> comparison chart of security-enhance Linux implementations.
> The current version can be found in
>
> http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

Smack Security Model: autolabel, as far as I can tell.
Smack Policy Generation: user - hand - and an editor
Apparmor tutorial (beats any FAQ at first):
ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Jan Engelhardt wrote:
 Apparmor tutorial (beats any FAQ at first):
   ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
   
Thanks for the high praise. Unfortunately that FTP site seems to not be
working. Some alternatives:

* My personal copy of the above video
  http://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi
* Similar talk at linux.conf.au 2007
  http://youtube.com/watch?v=EgrfmSm0NWs
* Similar talk at Defcon 2007
  http://video.google.com/videoplay?docid=-1731833784646588861hl=en

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

On Oct 30 2007 12:23, Toshiharu Harada wrote:

 Instead of pushing TOMOYO Linux, I started developing
 comparison chart of security-enhance Linux implementations.
 The current version can be found in

 http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

Smack Security Model: autolabel, as far as I can tell.
Smack Policy Generation: user - hand - and an editor
Apparmor tutorial (beats any FAQ at first):
ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Toshiharu Harada]

On 10/30/2007 5:40 PM, Jan Engelhardt wrote:

On Oct 30 2007 12:23, Toshiharu Harada wrote:

Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in

http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison


Smack Security Model: autolabel, as far as I can tell.

I noticed the smell of danger in the naming of Security Model.
Please allow me some time.


Smack Policy Generation: user - hand - and an editor
Apparmor tutorial (beats any FAQ at first):
ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi

Updated above two items. Thank you. :)

I'm not an optimist to believe we can reach the perfect
comparison. The purpose is to feed information, not to judge.
This might sound ironically, but I don't really think
we can *compare* them because they have different
theories/purposes/backgrounds. Some kind of forgiveness and
fuzziness are required.

As I don't want to steal everybody's bandwidth,
simple updates will be done silently. Your suggestions and
information will be greatly appreciated despite of
visible evidence.

Thank you.
Toshiharu Harada

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

On Oct 30 2007 01:50, Crispin Cowan wrote:
Jan Engelhardt wrote:
 Apparmor tutorial (beats any FAQ at first):
  ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
   
Thanks for the high praise. Unfortunately that FTP site seems to not be
working. Some alternatives:
[...]

Actually, if the selinux team would do the same [introductionary video],
I'd guess the hardness level commonly associated with selinux could be
relieved a bit.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Bernd Petrovitsch]

On Thu, 2007-10-25 at 09:04 -0700, Ray Lee wrote:
 On 10/25/07, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
  On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
  []
   Key-based masterlocks are easily broken with freon, and their combo
   locks are easily brute-forced in about ten minutes. Yet, I'll still
   use them to lock up my bike and garage.
 
  The question is what the security threat is and the value of the secured
  items.
 
   The idea that poor security is worse than no security is fallacious,
   and not backed up by common experience.
 
  The common experience is, that common people just *feel* safer (just
  because they have poor security).
 
 Do you lock your bike up when you leave it lying around? My point is
 that real security comes in layers, not one perfect solution that will
 always work everywhere for everyone. The latter is a pipe-dream.

Of course not. Security as such is more than less only risk
management (or part of it - depending of the viewpoint).

  With no security, they know that there is no security. With poor
  security, they do not know (or can deny) that they have next to no real
  security.
 
 The fallacy here is to believe that just because they have no
 security, that it will *in*any*way* change their behavior. I deal with
 real users daily, and *they*don't*care*. Further, there's no level of

If people don't care, they are pretty lost anyway.
That's actually the reason for all that security stuff that no one wants
but which stands in the way of all people just because of the don't
care faction (which by far the majority of all in any given area).
But there is that (also not too small) I installed $PERSONAL_FIREWALL
and *nothing* can happen because $VENDOR and $TECH_JOURNALIST in
$LOW_QUALITY_PC_MAG said so faction.

 education that we can instill into the community to make them aware of
 the issues and change their habits accordingly, because real users
 don't have the background to understand those lessons.
 
 While you can teach them that running an executable from someone they
 haven't heard of is obviously bad, they don't know why downloading an
 image is potentially dangerous, it's an image, right? Well, there's
 these things called buffer overflows... eyes glaze over
 
 Security is not an all or nothing game, it's layers. And we have to

And every layer/subsystem/area must be checked and seen independently of
others (or the dependency must be that strong that no one can work
around).
And every security layer will and should have it's purpose and targets.

 make sure that the layers are usable without taking a course from the
 NSA. I'd love to see a poll of the kernel development community to
 find out how many use SELinux on their machines, for example.

selinux=0 on the kernel commandline is normal - no unknown people have
logins and so there was no reason to learn it. And against should it
protect in the first place if only trusted people are there?

  The prime example here is the usual (so-called) personal firewall on
  Windows where people work normally as administrator.
 
 So your argument is that if there weren't a personal firewall on
 Windows, that a significant number of people would then not run as
 Administrator? I beg to differ.

No, how do you come to that conclusion?

People login as Administrator because they did it since DOS3.0.
People buy and install $PERSONAL_FIREWALL because some cheap PC tech
magazine had advertisements for them.
Next generation (or this generation?) viruses/malware will either
reconfigure $PERSONAL_FIREWALL silently (and if course only
temporarily).
And the vendor of $PERSONAL_FIREWALL writes into the manual (which no
one reads) or the EULA (which no one reads because it isn't relevant in
the first place) or some README (which no one finds) that one must not
login as Administrator. But that just to keep the vict^Wbuyers to not
sue them. And working on Win* without being Administrator is a real
PITA - so the average user won't do it for long.

So apart from the personal feelings of that user I can't find any sign
of security.

BTW from a commercial viewpoint, the (so-called) personal firewalls
were probably one of the best ideas (and another major example that
technical expertise has nothing to do with sales success).

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

(please do not drop Cc, or I would have lost this thread part if I had 
not been on lkml. And sometimes I am not because of the volume. Thanks.)

On Oct 30 2007 15:13, Peter Dolding wrote:
On 10/30/07, Crispin Cowan [EMAIL PROTECTED] wrote:

 * I have no clue what family to put MultiADM or Dazuko into

MultiADMIN falls under o my god head ache.  This is more a posix
standard feature altered ie 1 root user turned into many.  This really
risks breaking the other models as a LSM.

I disagree.

Traditionally, Linux has given a process all capabilities when the
UID changed to 0 (either by setuid(2) or executing a SUID binary).
This has been relieved over the years, and right now with LSMs in the
field, it is possible to 'deactivate' this special case for UID 0.

SELinux does not have this special case for UID 0. Neither does it
seem to use capabilities (quick grep through the source). So
basically, all users are the same, and no one has capabilities by
default. Does SELinux thus break with other LSMs?

Now assume a SELinux system where all users have all capabilities
(and the policy that is in place restricts the use of these
capabilities then) -- should not be that unlikely. Does that break
with other LSMs?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Casey Schaufler]

--- Jan Engelhardt [EMAIL PROTECTED] wrote:

 
 (please do not drop Cc, or I would have lost this thread part if I had 
 not been on lkml. And sometimes I am not because of the volume. Thanks.)
 
 On Oct 30 2007 15:13, Peter Dolding wrote:
 On 10/30/07, Crispin Cowan [EMAIL PROTECTED] wrote:
 
  * I have no clue what family to put MultiADM or Dazuko into
 
 MultiADMIN falls under o my god head ache.  This is more a posix
 standard feature altered ie 1 root user turned into many.  This really
 risks breaking the other models as a LSM.
 
 I disagree.
 
 Traditionally, Linux has given a process all capabilities when the
 UID changed to 0 (either by setuid(2) or executing a SUID binary).
 This has been relieved over the years, and right now with LSMs in the
 field, it is possible to 'deactivate' this special case for UID 0.
 
 SELinux does not have this special case for UID 0. Neither does it
 seem to use capabilities (quick grep through the source). So
 basically, all users are the same, and no one has capabilities by
 default. Does SELinux thus break with other LSMs?
 
 Now assume a SELinux system where all users have all capabilities
 (and the policy that is in place restricts the use of these
 capabilities then) -- should not be that unlikely. Does that break
 with other LSMs?

As some of the early Smack discussions brought out, some LSMs
including Smack will be perfectly happy with the traditional
Linux privilege mechanisms (choice of root and/or capablities)
while others including SELinux will go their own ways. So long
as LSMs are self contained and strictly restrictive the
mechanisms they use to modulate their behavior shouldn't be an
issue. If SELinux chooses to turn its MLS controls off between
midnight and 3am I can't see how that would be Smack's business,
even if they were somehow stacked. Multiple LSMs has issues,
like what should security_secid_to_secctx() return to the audit
system, but privilege model shouldn't be one of them.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

On Oct 30 2007 12:14, Casey Schaufler wrote:

while others including SELinux will go their own ways. So long
as LSMs are self contained and strictly restrictive the
mechanisms they use to modulate their behavior shouldn't be an
issue. If SELinux chooses to turn its MLS controls off between
midnight and 3am I can't see how that would be Smack's business,
even if they were somehow stacked. Multiple LSMs has issues,
like what should security_secid_to_secctx() return to the audit
system, but privilege model shouldn't be one of them.

I am with you on that. And for everybody who missed it: MultiAdmin
only grants rights at the same time commoncap does (e.g. on setuid
and bprm_set_security). And all modules DO work with commoncap, now
don't they?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

Jan Engelhardt wrote:

I disagree.

Traditionally, Linux has given a process all capabilities when the
UID changed to 0 (either by setuid(2) or executing a SUID binary).
This has been relieved over the years, and right now with LSMs in the
field, it is possible to 'deactivate' this special case for UID 0.
  
SELinux does not have this special case for UID 0. Neither does it

seem to use capabilities (quick grep through the source). So
basically, all users are the same, and no one has capabilities by
default. Does SELinux thus break with other LSMs?

Now assume a SELinux system where all users have all capabilities
(and the policy that is in place restricts the use of these
capabilities then) -- should not be that unlikely. Does that break
with other LSMs?
  
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules 
are applied over using Selinux rules.  This is just the way it is 
stacking LSM's is Just not healthy you always risk on LSM breaking 
another.  Part of the reason why I have suggested a complete redesign of 
LSM.  To get away from this problem of stacking.


I see MultiAdmin purely in the class of posix file capabilities( Fine 
grained replacement to SUID).
This is a standard feature fix not part of LSM.  Note it can not replace 
all SUID bits due to some internals of applications design need to be 
changed to support posix file capabilities in particular not checking if 
running as UID 0.  Traditional  UID 0 is already optional for 
applications without  LSM's.


Posix file capabilities only applies to applications only.  MultiAdmin 
being the user mirror of Posix file capabilities.


MultiAdmin patch to the user side may allow more SUID bits to be killed 
off from the start line.  So increasing overall system security.


Of course MultiAdmin might end up two halfs.   One a standard feature 
that hands out capabilities to users that LSMs can overrule.  And one a 
user by user directory access control LSM directory control LSM less 
likely to cause problems.


I really don't see the need for a LSM stacking order.  Some features 
just should not be LSM's in my eyes.  MultiAdmin is one of them.


Traditional way has all ready been expanded for applications without 
LSM's.  So my call still stand O heck head ache rating.   Because its in 
the wrong place.  Particularly when you think people will want to use it 
stacked with other LSM's.   Stacking should be avoided where able.   
This means at least some of Multiadmin features just have to be done 
core kernel as a normal kernel module to avoid stacking and breaking the 
LSM.


Note posix file capabilities was developed as a LSM module too at first 
the point came where it was going to cause more trouble for other LSMs 
granting stuff in conflict.Both Multiadmin and posix file 
capabilities share a lot in common.  Both developed in the wrong place.  
Both required to be else where.  Even there function is similar breaking 
down root powers and handing them out more effectively.  So in my eyes 
it is a pure Posix extension not a LSM.


Peter Dolding
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[david]

On Wed, 31 Oct 2007, Peter Dolding wrote:

MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are 
applied over using Selinux rules.  This is just the way it is stacking LSM's 
is Just not healthy you always risk on LSM breaking another.  Part of the 
reason why I have suggested a complete redesign of LSM.  To get away from 
this problem of stacking.


since the method of stacking hasn't been determined yet, you can't say 
this.


it would be possible for MultiAdmin to grant additional access, that 
SELinux then denies for it's own reasons.


if the SELinux policy is written so that it ignores capabilities, and 
instead just looks at uid0 then that policy is broken in a stacked 
environment, but it's the polciy that's broken, not the stacking.


yes, there will be interactions that don't make sense, but just becouse 
something can be used wrong doesn't mean that there aren't other cases 
where it can be used properly.


David Lang
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 10/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 On Wed, 31 Oct 2007, Peter Dolding wrote:

  MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
  applied over using Selinux rules.  This is just the way it is stacking LSM's
  is Just not healthy you always risk on LSM breaking another.  Part of the
  reason why I have suggested a complete redesign of LSM.  To get away from
  this problem of stacking.

 since the method of stacking hasn't been determined yet, you can't say
 this.

I can because that is the current day problem. With many LSM's loaded
they stack completely as a complete mess and with problems.  They
fight with each other.  Lack of define on stacking equals big
problems.   Since you have not created a standard for stacking does
not stop the problem from existing.  Nice lack of planing when LSM
started or maybe its intentional.  When you need stacking its about
time you start moving things into the OS?

There is a way around the problem too without allowing LSM to stack.
Good advantage backward compatible  because your are not playing with
the LSM standard to do it so no LSM modules should need large
alterations.  At worse mirror extensions to handle the new OS feature.
 Posix File Capabilities provide the solution.   First done as a LSM
risked conflict.   Moved in as a operating system extension by by
conflict.  Fragments from LSM's should exactly move that way if they
expect to be overlapped by other models.

Lot of stacking problems can be avoided if segments are complete
standard extensions.

 it would be possible for MultiAdmin to grant additional access, that
 SELinux then denies for it's own reasons.

 if the SELinux policy is written so that it ignores capabilities, and
 instead just looks at uid0 then that policy is broken in a stacked
 environment, but it's the polciy that's broken, not the stacking.

That is not how current day always works.  MultiAdmin grants and that
can be the end of the treeing.   Selinux does not get asked if it
refuses it or not.  So no matter what was set in the Selinux policy it
may never get used.   Adding more layers is also bad for performance
to.  Treeing threw modules for rights is a really slow process.  As
like a posix feature extension.   Selinux/Other LSM's is at top of
allocation no flaw no bypass.

 yes, there will be interactions that don't make sense, but just becouse
 something can be used wrong doesn't mean that there aren't other cases
 where it can be used properly.

We are talking security here if its not order safe its not good.
MultiAdmin done as a posix feature extension is order safe.
MultiAdmin done as a LSM is not order safe.

System Admins are humans too.  Getting orders backwards does happen.
So should be avoided where able.

This completely avoids the need for adding another layer of stacking
and since built inside current day framework.  Does doing this risk
the end of LSM's as we know it yes it does.  Since it is not being
used as LSM were intended.  LSM is just a addon to standard OS
security what is either a testing ground for new features to secure
the OS that get build into the OS in time or as location for security
modules.

Somethings should be just done in the Standard OS security nothing to
do with LSM.

Little bit hard for some I guess to hear that LSM are not all
important and not all Security features should be done in them.  Some
should be done in the main OS security features.

Biggest current day problem with LSM is they have forgot that LSM is
only a testing ground or a zone for features that people will only
want some of the time.

MultiAdmin is a feature that can enhance means to Audit OS ie who did
what.  Enhance security hand outs and can be really handy with almost
any LSM on the system.  Its description of what it is sounds very much
like every other standard feature.

Lets end the bitrot.  Start having bits go into the main OS security
features where they should be.

Peter Dolding
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Casey Schaufler]

--- Peter Dolding [EMAIL PROTECTED] wrote:


 Lets end the bitrot.  Start having bits go into the main OS security
 features where they should be.

Gawd. Sorry, but we lost that argument in 1986 and the situation
hasn't changed a bit since. Most people just don't want what we're
selling. Do you know why Unix was a success and MULTICS* a failure?
It's because Unix had mode bits and MULTICS had ACLs. Fortunately
for those of us who wear titles like Security Expert or Trust
Technologist with pride there are enough clinical paranoids in
positions of authority to keep the Trusted System niche from closing
up completely and hence supporting our Rock Star Lifestyles. The
good news is that the situation is no worse than that faced by
the people who are bringing you Infiniband or Itanium, neither of
which will ever be the life of the party either. Sure security is
important, but I learned (in college, and yes they had colleges
way back then) not to drink too much at parties I'd crashed.

LSM isn't all I want it to be either, but it's better than I ever
got in the Proprietary OS world, and that includes when the MLS
systems were bringing in $20million a pop. Trying to force features
that virtually no one wants into any system is a bad idea. If
you haven't read Man of LaMancha I strongly suggest you do so.
Or at least see the play, it's got some catchy songs.

-
* If you don't know what MULTICS was you can buy me a beer and
  I'll tell you the whole story


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[david]

On Wed, 31 Oct 2007, Peter Dolding wrote:


On 10/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

On Wed, 31 Oct 2007, Peter Dolding wrote:


MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
applied over using Selinux rules.  This is just the way it is stacking LSM's
is Just not healthy you always risk on LSM breaking another.  Part of the
reason why I have suggested a complete redesign of LSM.  To get away from
this problem of stacking.


since the method of stacking hasn't been determined yet, you can't say
this.


I can because that is the current day problem. With many LSM's loaded
they stack completely as a complete mess and with problems.  They
fight with each other.  Lack of define on stacking equals big
problems.   Since you have not created a standard for stacking does
not stop the problem from existing.  Nice lack of planing when LSM
started or maybe its intentional.  When you need stacking its about
time you start moving things into the OS?


the lack of a stacking ability was deliberate (go back and read the 
archives). basicly no LSM was willing to admit that they weren't the 
be-all, end-all of security, so nobody was willing to consider that anyone 
would ever want anything else.


one method of doing the stacking would be for the LSM to not know about 
the stacking, but the kernel takes care of passing all requests through 
each LSM in order (if the LSMs can be staticly compiled the order should 
be able to be changed at compile time)


now, the existing policies for some LSM's may need to change, becouse 
they've been assuming that they only needed to check capabilities for 
UID=0, when they will now need to check them for everyone, but arguably, 
this was a bug masquerading as an optimization in the first place.



There is a way around the problem too without allowing LSM to stack.
Good advantage backward compatible  because your are not playing with
the LSM standard to do it so no LSM modules should need large
alterations.  At worse mirror extensions to handle the new OS feature.
Posix File Capabilities provide the solution.   First done as a LSM
risked conflict.   Moved in as a operating system extension by by
conflict.  Fragments from LSM's should exactly move that way if they
expect to be overlapped by other models.

Lot of stacking problems can be avoided if segments are complete
standard extensions.


which LSM gets to declare the standards?



it would be possible for MultiAdmin to grant additional access, that
SELinux then denies for it's own reasons.

if the SELinux policy is written so that it ignores capabilities, and
instead just looks at uid0 then that policy is broken in a stacked
environment, but it's the polciy that's broken, not the stacking.


That is not how current day always works.  MultiAdmin grants and that
can be the end of the treeing.   Selinux does not get asked if it
refuses it or not.  So no matter what was set in the Selinux policy it
may never get used.   Adding more layers is also bad for performance
to.  Treeing threw modules for rights is a really slow process.  As
like a posix feature extension.   Selinux/Other LSM's is at top of
allocation no flaw no bypass.


only if the stacking mode permits this. if it always requires passing 
through all the layers then this wouldn't be a problem.


Besides which, the MultiAdmin authors would probably be willing to make 
the nessasary changes to their LSM to play nicely with others anyway (but 
good programming practice would dictate that you don't count on it, and 
arrange for the other modules to approve as well)



yes, there will be interactions that don't make sense, but just becouse
something can be used wrong doesn't mean that there aren't other cases
where it can be used properly.


We are talking security here if its not order safe its not good.
MultiAdmin done as a posix feature extension is order safe.
MultiAdmin done as a LSM is not order safe.


as things are currently written, it's not possible to stack, so there is 
no order. change how things are written and you can make them safe.



System Admins are humans too.  Getting orders backwards does happen.
So should be avoided where able.


the sysadmins need to be given enough rope, you don't know everything that 
they are trying to do, and you don't know what other LSMs going to do. so 
how can you possibly decide ahead of time what orders are safe?



This completely avoids the need for adding another layer of stacking
and since built inside current day framework.  Does doing this risk
the end of LSM's as we know it yes it does.  Since it is not being
used as LSM were intended.  LSM is just a addon to standard OS
security what is either a testing ground for new features to secure
the OS that get build into the OS in time or as location for security
modules.

Somethings should be just done in the Standard OS security nothing to
do with LSM.

Little bit hard for some I guess to hear that LSM are not all
important and not 

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

[Crispin Cowan]

Peter Dolding wrote:
 Lets end the bitrot.  Start having bits go into the main OS security
 features where they should be.
   
Linus categorically rejected this idea, several times, very clearly.

He did so because the security community cannot agree on a
one-true-standard for what that OS security feature set should be. From
looking at this thread and many others, he is correct; there is no
consensus on what the feature set should be.

So you can wish for the main OS security features all you want, but it
is not going to happen without a miraculous degree of consensus abruptly
arising.

On the contrary, security, done well, is a tight fitting suit. It must
be tight, or it allows too much slack and attackers can exploit that. To
make it tight, it must be tailored to the situation at hand. That means
that there may *never* be a consensus on the one true way, because it
could be that there is no one true way. It could be that SMACK is best
in some cases, AppArmor in others, SELinux in others yet again, MLS in
others, etc. etc.

I agree with Casey; LSM may not be perfect, but it is a great deal more
consensus than I have seen anywhere else in the security community. Your
desire that AppArmor and SELinux should share code has already happened:
LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and
TOMOYO, and MultiADM, etc.

It certainly can be improved, but it is not in need of wholesale
replacement, and especially not without a clear design that addresses
clearly stated problems that lots of people are having.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 10/30/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Ah! So the proposal really is to have an LSM maintainer for each
> "family" of models, acting as a resource and arbiter for modules in a class.

I see it a little bit different one LSM maintainer for the lot of
modules who kicks the ass's of thoses who are not prepaid to share.
>
> I like that idea, and have no objection to it. However, it does have
> resource problems, in that the pool of LSM maintainers is not that
> large. There is also the likely objection that this degree of scale is
> not needed until at least there are multiple families of models in the
> upstream kernel, and possibly until there are multiple instances of a
> single family in the upstream kernel.
>
> It also begs the question of what constitutes a family.
>
> * AppArmor, SELinux, and TOMOYO are all ambient capability systems
>   o AppArmor and TOMOYO are pathname based
>   o SELinux is label based

Here as always all three should see where they can share code and get
the best performance this might mean AppArmor and Tomoyo use Selinux
labels because it causes less overhead.  Or Selinux provides a
optional path based using the other engine.  Both are providing the
same feature in different ways.   Question does have to be asked is
there bench testable justification for need two for file systems
filters.

> * SELinux and SMACK are label-based
>   o I don't know if SMACK is an ambient capability system

Both of these are sharing backwards and forwards between each other so
being nice with each other.  LSM overall Maintainer only really need
to at worst way xyz sections are not merged/shared and to document why
with benchmarks if they are not going to be.  Ie tested reason.

> * Rob Meijer implicitly advocated for an object capability LSM
>   o would it be pathname or label based? You could do either or
> both ...
Both is a valid answer.   Sections done path based should be shared
with other path based and labal based shared with other label based.

> * The LSPP work from RH, Tresys, and TCS is MLS based
>   o this is a subset of both label-based and ambient capability
> based
Ok section by section where would it be best for that code base to share with.

> * I have no clue what family to put MultiADM or Dazuko into
MultiADMIN falls under o my god head ache.  This is more a posix
standard feature altered ie 1 root user turned into many.  This really
risks breaking the other models as a LSM.  Its more of a all in or all
out.  Really it needs to be lowered out of LSM into a standard
optional Linux feature so it cannot breach the security of other LSM
modules.  Also LSM modules will need to be made able to tell a
MultiADMIN root users.  This is part of what I was talking about some
parts need to be as lower down module not at full blown LSM level.
This is the rare one where the complete model needs to be moved down.
There are bits in almost all LSM that need to be looked at being made
full time features of linux like quotas and posix file capability's .

Dazuko is the rare user mode controlled interface.  Still same rule
share code where able.  Anti-Virus integration and other protecting
systems are commonly overlooked by LSM's.Same here if this should
be a LSM or a kernel optional feature independent to LSM that a LSM
can block from happening.

> * Getting very formal, I could imagine a Clarke-Wilson module
> * Getting very informal, I could imagine a module that is a
>   collection of cute intrusion prevention hacks, such as the Open
>   wall Linux symlink and hardlink restrictions, and my own RaceGuard
>   work
>   o Oh wait, I published
> 
> RaceGuard. Does that make it formal? :-)
>
You will hate me but I don't call that formal enough.  Its lacks the
critical bit of doc written in terms that any system admin can
understand what they are being given.

Next question should RaceGuard be a LSM at all.  Or should it be a
standard feature what LSM can over rule? 

Lot of things are being pushed as LSM's when they should be pushed as
expanded default features outside LSM.

Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Toshiharu Harada]

On 10/25/2007 9:41 AM, Chris Wright wrote:

* Linus Torvalds ([EMAIL PROTECTED]) wrote:
Do other people want to stand up and be "LSM maintainers" in the sense 
that they also end up being informed members who can also stand up for new 
modules and help merge them, rather than just push the existing one(s)? 
Chris? Casey? Crispin?


Stephen and James, despite their clear bias towards SELinux, do try to
give good feedback.  But you are right, there's not enough active help
for people trying to make a contribution to get their code in shape.
Many of the modules that come along have been misguided conceptually,
but I think that e.g. apparmor, tomoyo, smack could use that kind
of constructive help to get into final mergable shape.  Personally,
I haven't spent nearly enough time reviewing those, my apologies to
those developers.  So, yes, help is welcome.


Yes, TOMOYO Linux is committed to help.
I mean, please count me in.

PS
Chris, I've been waiting for your comments for our code. :)

Regards,
Toshiharu Harada

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Toshiharu Harada]

On 10/25/2007 10:42 AM, 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 can't be any good if it doesn't
deal with all objects", or "the granularity isn't fine enough". Look
at TOMOYO. It's chuck full of good ideas. Why spend so much energy
badgering them about not dealing with sockets? How about helping the
AppArmor crew come up with acceptable implementations rather than
whinging about the evils of hard links? And maybe, just maybe, we can
get away from the inevitable claim that you could do that with a few
minutes work in SELinux policy, but only if you're a security
professional of course.


Casey,

Thank you introducing TOMOYO Linux. I really like your idea of
simplified MAC (and you work so hard!). I also find advantages
of AppArmor for distributing policies with less hustle. Finally
and most importantly, I respect SELinux as the first in-tree,
flexible and reliable security frame work and respect developers
involved.

As a project manager of TOMOYO Linux, I would like to
push it, of course. But I noticed, if each of LSM module
developer begin pushing their own code, that's not for the
sake of Linux and we may end up with chaos.

Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in

http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

I would like to receive feedbacks from Stephen, Crispin
(you already have a comparison, though :),
Casey and any people interested in. If possible,
I would like to include opinions from BSD people.

I would like LSM to be the result of common requirements.
"Common" means good in general, but not always for security
perspective. IMHO, I think it is possible for us to get to the
conclusion not to have a framework.

Cheers (and with love to Linux),
Toshiharu Harada

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Casey Schaufler]

--- Rob Meijer <[EMAIL PROTECTED]> wrote:


> > * The proposal only allows a single implementation of each formal
> >   model. In theory, theory is just like practice, but in practice it
> >   is not. SMACK and SELinux follow substantially similar formal
> >   models (not exactly the same) so should we exclude one and keep
> >   the other? No, of course not, because in practice they are very
> >   different.
> 
> I would think the two may benefit from a role as described above.
> But I was thinking more in the line of new modules that may again
> implement this same model, and would thus benefit from interaction with
> this 'model maintainer' role.

The Smack development has benefited greatly from comments, suggestions,
and bug reports from members of the SELinux community. Further, I have
had no trouble whatever sharing the netlabel component with SELinux.
Audit is another matter as it requires some work to get the SELinux
dependencies out, but everyone's been receptive to proposals there.
Why on earth would I want some 'model maintainer' passing judgements
on my work in progress? The only thing I can imagine a 'model
maintainer' doing is obstructing innovation. Unless it was me, of
course. Linus is right, you know.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Rob Meijer wrote:
> 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 model they are actualy using, thus resulting in
>>> cleaner module design.
>>>   
>> I *really* dislike this idea. It seems to set up the situation that the
>> only acceptable modules are those that follow some "formal" model.
>> Problems:
>> ...
>> * The proposal only allows a single implementation of each formal
>>   model. In theory, theory is just like practice, but in practice it
>>   is not. SMACK and SELinux follow substantially similar formal
>>   models (not exactly the same) so should we exclude one and keep
>>   the other? No, of course not, because in practice they are very
>>   different.
>> 
> I would think the two may benefit from a role as described above.
> But I was thinking more in the line of new modules that may again
> implement this same model, and would thus benefit from interaction with
> this 'model maintainer' role.
>   
Ah! So the proposal really is to have an LSM maintainer for each
"family" of models, acting as a resource and arbiter for modules in a class.

I like that idea, and have no objection to it. However, it does have
resource problems, in that the pool of LSM maintainers is not that
large. There is also the likely objection that this degree of scale is
not needed until at least there are multiple families of models in the
upstream kernel, and possibly until there are multiple instances of a
single family in the upstream kernel.

It also begs the question of what constitutes a family.

* AppArmor, SELinux, and TOMOYO are all ambient capability systems
  o AppArmor and TOMOYO are pathname based
  o SELinux is label based
* SELinux and SMACK are label-based
  o I don't know if SMACK is an ambient capability system
* Rob Meijer implicitly advocated for an object capability LSM
  o would it be pathname or label based? You could do either or
both ...
* The LSPP work from RH, Tresys, and TCS is MLS based
  o this is a subset of both label-based and ambient capability
based
* I have no clue what family to put MultiADM or Dazuko into
* Getting very formal, I could imagine a Clarke-Wilson module
* Getting very informal, I could imagine a module that is a
  collection of cute intrusion prevention hacks, such as the Open
  wall Linux symlink and hardlink restrictions, and my own RaceGuard
  work
  o Oh wait, I published

RaceGuard. Does that make it formal? :-)

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[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 model they are actualy using, thus resulting in
>> cleaner module design.
>>
> I *really* dislike this idea. It seems to set up the situation that the
> only acceptable modules are those that follow some "formal" model.
> Problems:
>
> * What qualifies as a formal model? This becomes an arbitrary litmus
>   test, depending on whether the model was originally published in a
>   sufficiently snooty forum.
> * What if someone invents a new model that has not been "formalized"
>   yet? Should Linux be forced to wait until the idea has been
>   through the academic mill before we allow someone to try
>   implementing a module for the idea?

I may have been stating things a bit to strong when talking only about
"formal" models only. But possibly you could just define the non-formal
experimental models as a single group.

The thing I was trying to propose was aimed at the problem that if someone
proposes a patch to the LSM base code that he/she feels is needed to
complete an LSM module that implements a particular (formal) model,
he/she would end up explaining and/or defending both the 'model', the module
and its requirement for the patch.

What I tried to propose is to assign some sort of maintainer role for each
(formal) model, and let these roles take care of the module/patch part of
stuff, while the module writer would only need to defend/discuss the the
patch with the model maintainer.

> * The proposal only allows a single implementation of each formal
>   model. In theory, theory is just like practice, but in practice it
>   is not. SMACK and SELinux follow substantially similar formal
>   models (not exactly the same) so should we exclude one and keep
>   the other? No, of course not, because in practice they are very
>   different.

I would think the two may benefit from a role as described above.
But I was thinking more in the line of new modules that may again
implement this same model, and would thus benefit from interaction with
this 'model maintainer' role.


Rob

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 10/29/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> I *really* dislike this idea. It seems to set up the situation that the
> only acceptable modules are those that follow some "formal" model. Problems:
>
> * What qualifies as a formal model? This becomes an arbitrary litmus
>   test, depending on whether the model was originally published in a
>   sufficiently snooty forum.

Agree slows development and experimentation with a idea BAD.  I would
more say function and reach of model and how its ment to operate
documented clearly.  So next coder along is not taken wild guess.  It
must be so clearly documented that almost any system admin could
understand how much or how little protection it is providing.

> * What if someone invents a new model that has not been "formalized"
>   yet? Should Linux be forced to wait until the idea has been
>   through the academic mill before we allow someone to try
>   implementing a module for the idea?

Experimental until documented out of tree following mine.
.
> * The proposal only allows a single implementation of each formal
>   model. In theory, theory is just like practice, but in practice it
>   is not. SMACK and SELinux follow substantially similar formal
>   models (not exactly the same) so should we exclude one and keep
>   the other? No, of course not, because in practice they are very
>   different.

Drop a stick on both of them.   Since they both operate substantially
similar they should be directly prepared to share code with each
other.   If one is not prepared to work with the other openly and
fairly out the tree it goes.

It could quite simple become the only thing different between Smack
and Selinux in they way they read configuration files.   Long term the
most user friendly and security solid modules win.  So long term one
wins short term any number of models.  We of course wait for that to
happen.  Note it could be agreement between coders.   Since they were
force to work as one if there is merit it will come out.  There is no
room for empire builders.   We need security builders.  Part of that
is getting your code examined by the most number of people able.

Same with apparmor vs selinux both can provide file access filtering.
So why two sets of code to do it.

LSM need a really strong maintainer prepared to beat a few ears in.
Or all we will endup with is usable modules.   Selinux pain in but to
configure no not really usable.   Maybe flaws in Smack so force to use
Selinux.  Apparmor too weak.

Basically a stack of trash is the current LSM model.  LSM's are fast
turning into x86 vs x86-64 bitrot all over again accept this time 100
times worse.  What is basically bitrot caused by not sharing.
Stackable modules maybe.  More important shared source code to do
stuff and common standards between LSM used where able.  This also
should make it simpler for new models to be added and experimented
with.  Since the new model may not need to redo all there hooking
system all over again.  Reduced security risk more tested code used in
new models.

Next more important extend security down into applications if
applications need it.   File access filtering would be a great feature
at the thread level.

We have enough LSM's to be hard. It a privilege to be in the main
kernel tree not a right.  Part of having a module in the Linux kernel
tree is a promise to do what is right for everyones security using the
kernel even if it means the end to your LSM's existence.  Part of
doing what is right is sharing of code.   All LSM developers should be
looking at there code and asking should this be like posix file caps
and for everyone.  Or should this be a LSM only feature because its
useless to everyone else.  From what I am seeing LSM maintainers don't
seam to think its part of the requirement to help other LSM's be
better even if theirs ends up losing.  Only if you are building a
Empire does it matter who wins or loses the long term of LSM's.   Only
thing that truly matter is that we get the best long term.


Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Rob Meijer wrote:
> What may be even more relevant are those concepts that couldn't be done
> in SELinux, and how proposals that come from the theory of alternative
> access controll models (like object capability modeling) are dismissed
> by the aparently largely MLS/MAC oriented people on the list.
Clearly what is needed here is for someone to actually implement an
object capability LSM module. None of SELinux, SMACK, LIDS, AppArmor,
MultiADM, or TOMOYO can implement object capabilities, so there is clear
justification for building such a module. I would argue strongly to
include it.

> 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 model they are actualy using, thus resulting in
> cleaner module design.
>   
I *really* dislike this idea. It seems to set up the situation that the
only acceptable modules are those that follow some "formal" model. Problems:

* What qualifies as a formal model? This becomes an arbitrary litmus
  test, depending on whether the model was originally published in a
  sufficiently snooty forum.
* What if someone invents a new model that has not been "formalized"
  yet? Should Linux be forced to wait until the idea has been
  through the academic mill before we allow someone to try
  implementing a module for the idea?
* The proposal only allows a single implementation of each formal
  model. In theory, theory is just like practice, but in practice it
  is not. SMACK and SELinux follow substantially similar formal
  models (not exactly the same) so should we exclude one and keep
  the other? No, of course not, because in practice they are very
  different.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[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 can't be any good if it doesn't
> deal with all objects", or "the granularity isn't fine enough". Look
> at TOMOYO. It's chuck full of good ideas. Why spend so much energy
> badgering them about not dealing with sockets? How about helping the
> AppArmor crew come up with acceptable implementations rather than
> whinging about the evils of hard links? And maybe, just maybe, we can
> get away from the inevitable claim that you could do that with a few
> minutes work in SELinux policy, but only if you're a security
> professional of course.

What may be even more relevant are those concepts that couldn't be done
in SELinux, and how proposals that come from the theory of alternative
access controll models (like object capability modeling) are dismissed
by the aparently largely MLS/MAC oriented people on the list.

In a wider contect than just this list, it apears to me that MLS and
Obj Caps advocates simply dismiss the alternative models as broken or as
irrelevant at best. In my view this attitude is very much pressent on
the MLS list.

It might in the light of this attitude even be a viable option to just
simply spin off 3 (or more) sets of LSM module sets, and maybe even put
some ifdefs in the base code depending on the chosen access controll model,
if for some reason the 'model' warants some major patch.

To me it would look like a good concept if LSM/Linux would try to support
all exisiting formal models of access controll, but without the need to
support all implementation alternatives for these models. That is, if a
module 'requires' a patch but the underlaying formal model does not, than
it would seem reasonable that the module be fixed. If however the 'model'
seems to require the patch, it may be perfectly reasonable for this patch
to be implemented, if need be with an ifdef for the used model.

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 model they are actualy using, thus resulting in
cleaner module design.



Rob

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[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 can't be any good if it doesn't
 deal with all objects, or the granularity isn't fine enough. Look
 at TOMOYO. It's chuck full of good ideas. Why spend so much energy
 badgering them about not dealing with sockets? How about helping the
 AppArmor crew come up with acceptable implementations rather than
 whinging about the evils of hard links? And maybe, just maybe, we can
 get away from the inevitable claim that you could do that with a few
 minutes work in SELinux policy, but only if you're a security
 professional of course.

What may be even more relevant are those concepts that couldn't be done
in SELinux, and how proposals that come from the theory of alternative
access controll models (like object capability modeling) are dismissed
by the aparently largely MLS/MAC oriented people on the list.

In a wider contect than just this list, it apears to me that MLS and
Obj Caps advocates simply dismiss the alternative models as broken or as
irrelevant at best. In my view this attitude is very much pressent on
the MLS list.

It might in the light of this attitude even be a viable option to just
simply spin off 3 (or more) sets of LSM module sets, and maybe even put
some ifdefs in the base code depending on the chosen access controll model,
if for some reason the 'model' warants some major patch.

To me it would look like a good concept if LSM/Linux would try to support
all exisiting formal models of access controll, but without the need to
support all implementation alternatives for these models. That is, if a
module 'requires' a patch but the underlaying formal model does not, than
it would seem reasonable that the module be fixed. If however the 'model'
seems to require the patch, it may be perfectly reasonable for this patch
to be implemented, if need be with an ifdef for the used model.

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 model they are actualy using, thus resulting in
cleaner module design.



Rob

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Rob Meijer wrote:
 What may be even more relevant are those concepts that couldn't be done
 in SELinux, and how proposals that come from the theory of alternative
 access controll models (like object capability modeling) are dismissed
 by the aparently largely MLS/MAC oriented people on the list.
Clearly what is needed here is for someone to actually implement an
object capability LSM module. None of SELinux, SMACK, LIDS, AppArmor,
MultiADM, or TOMOYO can implement object capabilities, so there is clear
justification for building such a module. I would argue strongly to
include it.

 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 model they are actualy using, thus resulting in
 cleaner module design.
   
I *really* dislike this idea. It seems to set up the situation that the
only acceptable modules are those that follow some formal model. Problems:

* What qualifies as a formal model? This becomes an arbitrary litmus
  test, depending on whether the model was originally published in a
  sufficiently snooty forum.
* What if someone invents a new model that has not been formalized
  yet? Should Linux be forced to wait until the idea has been
  through the academic mill before we allow someone to try
  implementing a module for the idea?
* The proposal only allows a single implementation of each formal
  model. In theory, theory is just like practice, but in practice it
  is not. SMACK and SELinux follow substantially similar formal
  models (not exactly the same) so should we exclude one and keep
  the other? No, of course not, because in practice they are very
  different.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 10/29/07, Crispin Cowan [EMAIL PROTECTED] wrote:
 I *really* dislike this idea. It seems to set up the situation that the
 only acceptable modules are those that follow some formal model. Problems:

 * What qualifies as a formal model? This becomes an arbitrary litmus
   test, depending on whether the model was originally published in a
   sufficiently snooty forum.

Agree slows development and experimentation with a idea BAD.  I would
more say function and reach of model and how its ment to operate
documented clearly.  So next coder along is not taken wild guess.  It
must be so clearly documented that almost any system admin could
understand how much or how little protection it is providing.

 * What if someone invents a new model that has not been formalized
   yet? Should Linux be forced to wait until the idea has been
   through the academic mill before we allow someone to try
   implementing a module for the idea?

Experimental until documented out of tree following mine.
.
 * The proposal only allows a single implementation of each formal
   model. In theory, theory is just like practice, but in practice it
   is not. SMACK and SELinux follow substantially similar formal
   models (not exactly the same) so should we exclude one and keep
   the other? No, of course not, because in practice they are very
   different.

Drop a stick on both of them.   Since they both operate substantially
similar they should be directly prepared to share code with each
other.   If one is not prepared to work with the other openly and
fairly out the tree it goes.

It could quite simple become the only thing different between Smack
and Selinux in they way they read configuration files.   Long term the
most user friendly and security solid modules win.  So long term one
wins short term any number of models.  We of course wait for that to
happen.  Note it could be agreement between coders.   Since they were
force to work as one if there is merit it will come out.  There is no
room for empire builders.   We need security builders.  Part of that
is getting your code examined by the most number of people able.

Same with apparmor vs selinux both can provide file access filtering.
So why two sets of code to do it.

LSM need a really strong maintainer prepared to beat a few ears in.
Or all we will endup with is usable modules.   Selinux pain in but to
configure no not really usable.   Maybe flaws in Smack so force to use
Selinux.  Apparmor too weak.

Basically a stack of trash is the current LSM model.  LSM's are fast
turning into x86 vs x86-64 bitrot all over again accept this time 100
times worse.  What is basically bitrot caused by not sharing.
Stackable modules maybe.  More important shared source code to do
stuff and common standards between LSM used where able.  This also
should make it simpler for new models to be added and experimented
with.  Since the new model may not need to redo all there hooking
system all over again.  Reduced security risk more tested code used in
new models.

Next more important extend security down into applications if
applications need it.   File access filtering would be a great feature
at the thread level.

We have enough LSM's to be hard. It a privilege to be in the main
kernel tree not a right.  Part of having a module in the Linux kernel
tree is a promise to do what is right for everyones security using the
kernel even if it means the end to your LSM's existence.  Part of
doing what is right is sharing of code.   All LSM developers should be
looking at there code and asking should this be like posix file caps
and for everyone.  Or should this be a LSM only feature because its
useless to everyone else.  From what I am seeing LSM maintainers don't
seam to think its part of the requirement to help other LSM's be
better even if theirs ends up losing.  Only if you are building a
Empire does it matter who wins or loses the long term of LSM's.   Only
thing that truly matter is that we get the best long term.


Peter Dolding
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[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 model they are actualy using, thus resulting in
 cleaner module design.

 I *really* dislike this idea. It seems to set up the situation that the
 only acceptable modules are those that follow some formal model.
 Problems:

 * What qualifies as a formal model? This becomes an arbitrary litmus
   test, depending on whether the model was originally published in a
   sufficiently snooty forum.
 * What if someone invents a new model that has not been formalized
   yet? Should Linux be forced to wait until the idea has been
   through the academic mill before we allow someone to try
   implementing a module for the idea?

I may have been stating things a bit to strong when talking only about
formal models only. But possibly you could just define the non-formal
experimental models as a single group.

The thing I was trying to propose was aimed at the problem that if someone
proposes a patch to the LSM base code that he/she feels is needed to
complete an LSM module that implements a particular (formal) model,
he/she would end up explaining and/or defending both the 'model', the module
and its requirement for the patch.

What I tried to propose is to assign some sort of maintainer role for each
(formal) model, and let these roles take care of the module/patch part of
stuff, while the module writer would only need to defend/discuss the the
patch with the model maintainer.

 * The proposal only allows a single implementation of each formal
   model. In theory, theory is just like practice, but in practice it
   is not. SMACK and SELinux follow substantially similar formal
   models (not exactly the same) so should we exclude one and keep
   the other? No, of course not, because in practice they are very
   different.

I would think the two may benefit from a role as described above.
But I was thinking more in the line of new modules that may again
implement this same model, and would thus benefit from interaction with
this 'model maintainer' role.


Rob

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Casey Schaufler]

--- Rob Meijer [EMAIL PROTECTED] wrote:


  * The proposal only allows a single implementation of each formal
model. In theory, theory is just like practice, but in practice it
is not. SMACK and SELinux follow substantially similar formal
models (not exactly the same) so should we exclude one and keep
the other? No, of course not, because in practice they are very
different.
 
 I would think the two may benefit from a role as described above.
 But I was thinking more in the line of new modules that may again
 implement this same model, and would thus benefit from interaction with
 this 'model maintainer' role.

The Smack development has benefited greatly from comments, suggestions,
and bug reports from members of the SELinux community. Further, I have
had no trouble whatever sharing the netlabel component with SELinux.
Audit is another matter as it requires some work to get the SELinux
dependencies out, but everyone's been receptive to proposals there.
Why on earth would I want some 'model maintainer' passing judgements
on my work in progress? The only thing I can imagine a 'model
maintainer' doing is obstructing innovation. Unless it was me, of
course. Linus is right, you know.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Rob Meijer wrote:
 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 model they are actualy using, thus resulting in
 cleaner module design.
   
 I *really* dislike this idea. It seems to set up the situation that the
 only acceptable modules are those that follow some formal model.
 Problems:
 ...
 * The proposal only allows a single implementation of each formal
   model. In theory, theory is just like practice, but in practice it
   is not. SMACK and SELinux follow substantially similar formal
   models (not exactly the same) so should we exclude one and keep
   the other? No, of course not, because in practice they are very
   different.
 
 I would think the two may benefit from a role as described above.
 But I was thinking more in the line of new modules that may again
 implement this same model, and would thus benefit from interaction with
 this 'model maintainer' role.
   
Ah! So the proposal really is to have an LSM maintainer for each
family of models, acting as a resource and arbiter for modules in a class.

I like that idea, and have no objection to it. However, it does have
resource problems, in that the pool of LSM maintainers is not that
large. There is also the likely objection that this degree of scale is
not needed until at least there are multiple families of models in the
upstream kernel, and possibly until there are multiple instances of a
single family in the upstream kernel.

It also begs the question of what constitutes a family.

* AppArmor, SELinux, and TOMOYO are all ambient capability systems
  o AppArmor and TOMOYO are pathname based
  o SELinux is label based
* SELinux and SMACK are label-based
  o I don't know if SMACK is an ambient capability system
* Rob Meijer implicitly advocated for an object capability LSM
  o would it be pathname or label based? You could do either or
both ...
* The LSPP work from RH, Tresys, and TCS is MLS based
  o this is a subset of both label-based and ambient capability
based
* I have no clue what family to put MultiADM or Dazuko into
* Getting very formal, I could imagine a Clarke-Wilson module
* Getting very informal, I could imagine a module that is a
  collection of cute intrusion prevention hacks, such as the Open
  wall Linux symlink and hardlink restrictions, and my own RaceGuard
  work
  o Oh wait, I published
http://citeseer.ist.psu.edu/cowan01raceguard.html
RaceGuard. Does that make it formal? :-)

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Toshiharu Harada]

On 10/25/2007 10:42 AM, 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 can't be any good if it doesn't
deal with all objects, or the granularity isn't fine enough. Look
at TOMOYO. It's chuck full of good ideas. Why spend so much energy
badgering them about not dealing with sockets? How about helping the
AppArmor crew come up with acceptable implementations rather than
whinging about the evils of hard links? And maybe, just maybe, we can
get away from the inevitable claim that you could do that with a few
minutes work in SELinux policy, but only if you're a security
professional of course.


Casey,

Thank you introducing TOMOYO Linux. I really like your idea of
simplified MAC (and you work so hard!). I also find advantages
of AppArmor for distributing policies with less hustle. Finally
and most importantly, I respect SELinux as the first in-tree,
flexible and reliable security frame work and respect developers
involved.

As a project manager of TOMOYO Linux, I would like to
push it, of course. But I noticed, if each of LSM module
developer begin pushing their own code, that's not for the
sake of Linux and we may end up with chaos.

Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in

http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

I would like to receive feedbacks from Stephen, Crispin
(you already have a comparison, though :),
Casey and any people interested in. If possible,
I would like to include opinions from BSD people.

I would like LSM to be the result of common requirements.
Common means good in general, but not always for security
perspective. IMHO, I think it is possible for us to get to the
conclusion not to have a framework.

Cheers (and with love to Linux),
Toshiharu Harada

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Toshiharu Harada]

On 10/25/2007 9:41 AM, Chris Wright wrote:

* Linus Torvalds ([EMAIL PROTECTED]) wrote:
Do other people want to stand up and be LSM maintainers in the sense 
that they also end up being informed members who can also stand up for new 
modules and help merge them, rather than just push the existing one(s)? 
Chris? Casey? Crispin?


Stephen and James, despite their clear bias towards SELinux, do try to
give good feedback.  But you are right, there's not enough active help
for people trying to make a contribution to get their code in shape.
Many of the modules that come along have been misguided conceptually,
but I think that e.g. apparmor, tomoyo, smack could use that kind
of constructive help to get into final mergable shape.  Personally,
I haven't spent nearly enough time reviewing those, my apologies to
those developers.  So, yes, help is welcome.


Yes, TOMOYO Linux is committed to help.
I mean, please count me in.

PS
Chris, I've been waiting for your comments for our code. :)

Regards,
Toshiharu Harada

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 10/30/07, Crispin Cowan [EMAIL PROTECTED] wrote:
 Ah! So the proposal really is to have an LSM maintainer for each
 family of models, acting as a resource and arbiter for modules in a class.

I see it a little bit different one LSM maintainer for the lot of
modules who kicks the ass's of thoses who are not prepaid to share.

 I like that idea, and have no objection to it. However, it does have
 resource problems, in that the pool of LSM maintainers is not that
 large. There is also the likely objection that this degree of scale is
 not needed until at least there are multiple families of models in the
 upstream kernel, and possibly until there are multiple instances of a
 single family in the upstream kernel.

 It also begs the question of what constitutes a family.

 * AppArmor, SELinux, and TOMOYO are all ambient capability systems
   o AppArmor and TOMOYO are pathname based
   o SELinux is label based

Here as always all three should see where they can share code and get
the best performance this might mean AppArmor and Tomoyo use Selinux
labels because it causes less overhead.  Or Selinux provides a
optional path based using the other engine.  Both are providing the
same feature in different ways.   Question does have to be asked is
there bench testable justification for need two for file systems
filters.

 * SELinux and SMACK are label-based
   o I don't know if SMACK is an ambient capability system

Both of these are sharing backwards and forwards between each other so
being nice with each other.  LSM overall Maintainer only really need
to at worst way xyz sections are not merged/shared and to document why
with benchmarks if they are not going to be.  Ie tested reason.

 * Rob Meijer implicitly advocated for an object capability LSM
   o would it be pathname or label based? You could do either or
 both ...
Both is a valid answer.   Sections done path based should be shared
with other path based and labal based shared with other label based.

 * The LSPP work from RH, Tresys, and TCS is MLS based
   o this is a subset of both label-based and ambient capability
 based
Ok section by section where would it be best for that code base to share with.

 * I have no clue what family to put MultiADM or Dazuko into
MultiADMIN falls under o my god head ache.  This is more a posix
standard feature altered ie 1 root user turned into many.  This really
risks breaking the other models as a LSM.  Its more of a all in or all
out.  Really it needs to be lowered out of LSM into a standard
optional Linux feature so it cannot breach the security of other LSM
modules.  Also LSM modules will need to be made able to tell a
MultiADMIN root users.  This is part of what I was talking about some
parts need to be as lower down module not at full blown LSM level.
This is the rare one where the complete model needs to be moved down.
There are bits in almost all LSM that need to be looked at being made
full time features of linux like quotas and posix file capability's .

Dazuko is the rare user mode controlled interface.  Still same rule
share code where able.  Anti-Virus integration and other protecting
systems are commonly overlooked by LSM's.Same here if this should
be a LSM or a kernel optional feature independent to LSM that a LSM
can block from happening.

 * Getting very formal, I could imagine a Clarke-Wilson module
 * Getting very informal, I could imagine a module that is a
   collection of cute intrusion prevention hacks, such as the Open
   wall Linux symlink and hardlink restrictions, and my own RaceGuard
   work
   o Oh wait, I published
 http://citeseer.ist.psu.edu/cowan01raceguard.html
 RaceGuard. Does that make it formal? :-)

You will hate me but I don't call that formal enough.  Its lacks the
critical bit of doc written in terms that any system admin can
understand what they are being given.

Next question should RaceGuard be a LSM at all.  Or should it be a
standard feature what LSM can over rule? Swap RaceGuard out standard
question for all new LSM's and LSM features

Lot of things are being pushed as LSM's when they should be pushed as
expanded default features outside LSM.

Peter Dolding
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Arjan van de Ven]

On Sun, 28 Oct 2007 15:08:56 -0700
Crispin Cowan <[EMAIL PROTECTED]> wrote:

> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.

exactly; this is why I've been pushing recently for each new LSM to at
least document and make explicit what it tries to protect / protect
against (threat model and defense model in traditional security terms).
Without such an explicit description it's both impossible to
"neutrally" review a proposed LSM towards its goals, and it ends up as
a result with people making assumptions and attacking the model because
there's no separation between code and model.

 
> Exception: it is valid to say that the self-stated goal is too narrow
> to be useful. But IMHO that bar of "too narrow" should be very, very
> low. Defenses against specific modes of attack would be a fine thing
> to build up in the library of LSMs, especially if we got a decent
> stacking module so that they could be composed.

again I agree pretty much; I do want to reserve some minimum "common
sense" bar because people may (and probably will) do silly things withs
LSMs that are really not the right thing to do objectively.


-- 
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 10/29/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.

LSM is providing bad security on two fronts.

Number 1 LSM are speeding effort to create features.  Apparmor and
Selinux both provide file access filtering from applications.  Yet
they double up the code to do it.   So they cannot be used with each
other without doubling up hooks.  Then other LSM are creating there
own sections of code to do the same thing.   Simple rule more code
more risk of bugs since it will be less audited.  Duplication defense
features is really bad for security.  Some how code sharing has to be
got into LSM construction.

Number 2 The critical bit LSM stop at the edges of applications.   Now
without overlapping my hooks with existing LSMs I cannot create
application level protections.  Overlapping hooks will cause speed
loss.

LSM is set to protect the application. But inside the application
there will be sections that need the access rights and others that
don't.  Now a exploit in any section of the application under LSM gets
the LSM assigned rights.   With application level this can be done a
few ways extension to elf that is create by the complier and api calls
lowering access functions of current thread or for a starting thread.
If you exploit a section of the code without access to disk network
access and so on and without the right to call any function that does
that.   What have you exploited.   Minor data damage compared to
complete data that the application have access to being stolen as what
is the case with LSM at moment.  Basically LSM prevent taking control
of the complete system but don't help to stop peoples private data
from being stolen.  Both are bad to happen to a person.

LSM design is there to help security development not get in its way or
to cause bitrot.  Currently LSM design is causing major risk bitrot in
duplicated code.

Reading and processing configuration files should be independent to
the protection methods.   Hopefully designed to be able to run user
mode to test if the new profile for a application is safe to add
before adding it to the OS.   Typo prevention on both sides.  Current
method of just sticking everything into one huge blob is preventing
code sharing and risking more security holes.

The current LSM design is bad on so many levels.  I am surprised that
it takes a Non PHD System Admin to see it.  Some how I think its a
empire thing.   If everything was just simple blocks a person could
write a new LSM in hours with pretty good security.  Compared to
todays long time trying effort.  Leads of Apparmor selinux and so on
not being prepared to give up there little empire for the greater
good.

I personally hate stacking as a idea.  I personally prefer two layers
only.  Config reading and  enforcement.   Of course that does not stop
applications being assigned to different config reading systems.
Depth the two layers should stay fixed even if you have many different
models in use.

All LSM seam to want to force System Admins to pick there LSM over
another.   Instead of being able to pick LSM for task at hand.   Same
with poor security being better than no security its true.  Its
nothing strange to find selinux based systems with there security
disabled because the Admin cannot configure it.   But the reverse is
also true that when you have skilled Admins stuck with a system like
Apparmor cannot harden the system as far as they could with selinux.
Both ways its causing security holes poor security when you should
have good security is bad too.  Part of the problem LSM maintainers
are not at the front lines is all I can guess.  Because they don't
seam to know what is really needed.

Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.

That seems to be an appropriate test.

> Exception: it is valid to say that the self-stated goal is too narrow to
> be useful. But IMHO that bar of "too narrow" should be very, very low.
> Defenses against specific modes of attack would be a fine thing to build
> up in the library of LSMs, especially if we got a decent stacking module
> so that they could be composed.

Once you have stacking then it actually at times will make sense to have
security modules that do one very precise thing and do it well.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Alan Cox wrote:
>> The idea that poor security is worse than no security is fallacious,
>> and not backed up by common experience.
>> 
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.
> In particular stuff which makes users think they are secure but is
> worthless is very dangerous indeed.
>
> When you know that security is limited you act appropriately, when you
> believe security is good but it is not you take inappropriate risks and
> get badly burned.
>   
The "bad security is worse than no security" idea comes exactly from
what Alan says above: it happens when the security is not as good as you
think it is, and so you don't take adequate precautions.

Using the ongoing bicycle lock example, the discovery a few years ago
that a certain model of Kryptonite bike lock could be picked with a
simple pen made the security on this otherwise very sturdy lock become
abruptly very weak http://www.wired.com/culture/lifestyle/news/2004/09/64987

Conversely, the case can also be made that "weak security is better than
no security". It is better to secure your bike with a $10 lock than no
lock. If someone insists on only "high" security bike locks that cost
$1000 and weigh 30 lbs, then most people will choose to not lock their
bikes, or skip biking all together.

IMHO, much of the criticism leveled at proposed LSMs has been of the
latter kind, or worse. That the security of the proposed LSM does not
meet some particular use case does not make it "bad", it makes it not
for that use case.

To reject an LSM for providing "bad" security, IMHO you should have to
show how it is possible to subvert the self-stated goals of that LSM.
Complaints that the LSM fails to meet some goal outside of its stated
purpose is irrelevant. Conjecture that it probably can be violated
because of $contrivance is just so much FUD.

Exception: it is valid to say that the self-stated goal is too narrow to
be useful. But IMHO that bar of "too narrow" should be very, very low.
Defenses against specific modes of attack would be a fine thing to build
up in the library of LSMs, especially if we got a decent stacking module
so that they could be composed.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Hua Zhong]

I think you may be misinterpreting the word "poor" here.

Many people in this thread consider a security solution "poor" because it's
not "complete" or "perfect": it may work against attack ABC but not attack
XYZ. The defendants say that XYZ isn't possible in the environment that it's
supposed to be used, or XYZ may be too expensive to be worth implementing,
or they just are rare enough to be ignored. Heck, all security solutions
could be broke given physical access.

Implementing a security solution has a cost. Bypassing it also has a cost.
Sometimes it's economy, not technique, decides whether a particular security
solution is a good one.

Locks are a good example for this. It has a low cost/effect ratio, and very
easy to use. Is it 100% safe? Definitely not. People lock their bikes to a
tree when they enter a supermarket because it's reasonably safe. But leaving
their bikes like that over a few nights on a downtown street? Probably not a
good idea. Don't assume all people are idiots who do not know that (ok, some
people are, so the lock's manual states "it can be bypassed by a skilled
thief").

But what tapes are good for? I don't know what kind of value it adds to the
discussion.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-kernel-
> [EMAIL PROTECTED] On Behalf Of Pavel Machek
> Sent: Saturday, October 27, 2007 11:29 AM
> To: Ray Lee
> Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
> linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
> Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
> Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
> Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
> static interface)
> 
> Hi!
> 
> > > > The idea that poor security is worse than no security is
> fallacious,
> > > > and not backed up by common experience.
> > >
> > > There is a ton of evidence both in computing and outside of it
> which
> > > shows that poor security can be very much worse than no security at
> all.
> >
> > (So, I take it that you *don't* lock your bike up, as poor security
> is
> > worse than none?)
> 
> I do lock my bike with combination lock I found somewhere and cracked
> in five minutes... sometimes.
> 
> But do you suggest that I use paper tape to 'lock' my bike to
> streetlight? You just said that poor security is better than none,
> right?
> 
>   Pavel
> --
> (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 [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Hua Zhong]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-kernel-
> [EMAIL PROTECTED] On Behalf Of Pavel Machek
> Sent: Saturday, October 27, 2007 11:29 AM
> To: Ray Lee
> Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
> linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
> Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
> Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
> Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
> static interface)
> 
> Hi!
> 
> > > > The idea that poor security is worse than no security is
> fallacious,
> > > > and not backed up by common experience.
> > >
> > > There is a ton of evidence both in computing and outside of it
> which
> > > shows that poor security can be very much worse than no security at
> all.
> >
> > (So, I take it that you *don't* lock your bike up, as poor security
> is
> > worse than none?)
> 
> I do lock my bike with combination lock I found somewhere and cracked
> in five minutes... sometimes.
> 
> But do you suggest that I use paper tape to 'lock' my bike to
> streetlight? You just said that poor security is better than none,
> right?
> 
>   Pavel
> --
> (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 [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Pavel Machek]

Hi!

> > > The idea that poor security is worse than no security is fallacious,
> > > and not backed up by common experience.
> >
> > There is a ton of evidence both in computing and outside of it which
> > shows that poor security can be very much worse than no security at all.
> 
> (So, I take it that you *don't* lock your bike up, as poor security is
> worse than none?)

I do lock my bike with combination lock I found somewhere and cracked
in five minutes... sometimes.

But do you suggest that I use paper tape to 'lock' my bike to
streetlight? You just said that poor security is better than none,
right?

Pavel
-- 
(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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Pavel Machek]

Hi!

> but require unreasonable interface changes. As people who care
> about security (y'all who are only from the LKML are excused) it
> is our obligation to look beyond the preconceived notions of what
> is and isn't secure. Security is subjective. It's how you feel
> about it.

Hmm. So lets add automagic security module. It magically fixes
security holes, and you can feel good about it.


Pavel
-- 
(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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Pavel Machek]

Hi!

 but require unreasonable interface changes. As people who care
 about security (y'all who are only from the LKML are excused) it
 is our obligation to look beyond the preconceived notions of what
 is and isn't secure. Security is subjective. It's how you feel
 about it.

sarcasmHmm. So lets add automagic security module. It magically fixes
security holes, and you can feel good about it./sarcasm


Pavel
-- 
(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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Pavel Machek]

Hi!

   The idea that poor security is worse than no security is fallacious,
   and not backed up by common experience.
 
  There is a ton of evidence both in computing and outside of it which
  shows that poor security can be very much worse than no security at all.
 
 (So, I take it that you *don't* lock your bike up, as poor security is
 worse than none?)

I do lock my bike with combination lock I found somewhere and cracked
in five minutes... sometimes.

But do you suggest that I use paper tape to 'lock' my bike to
streetlight? You just said that poor security is better than none,
right?

Pavel
-- 
(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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Hua Zhong]

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linux-kernel-
 [EMAIL PROTECTED] On Behalf Of Pavel Machek
 Sent: Saturday, October 27, 2007 11:29 AM
 To: Ray Lee
 Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
 linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
 Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
 Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
 Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
 static interface)
 
 Hi!
 
The idea that poor security is worse than no security is
 fallacious,
and not backed up by common experience.
  
   There is a ton of evidence both in computing and outside of it
 which
   shows that poor security can be very much worse than no security at
 all.
 
  (So, I take it that you *don't* lock your bike up, as poor security
 is
  worse than none?)
 
 I do lock my bike with combination lock I found somewhere and cracked
 in five minutes... sometimes.
 
 But do you suggest that I use paper tape to 'lock' my bike to
 streetlight? You just said that poor security is better than none,
 right?
 
   Pavel
 --
 (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 [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Hua Zhong]

I think you may be misinterpreting the word poor here.

Many people in this thread consider a security solution poor because it's
not complete or perfect: it may work against attack ABC but not attack
XYZ. The defendants say that XYZ isn't possible in the environment that it's
supposed to be used, or XYZ may be too expensive to be worth implementing,
or they just are rare enough to be ignored. Heck, all security solutions
could be broke given physical access.

Implementing a security solution has a cost. Bypassing it also has a cost.
Sometimes it's economy, not technique, decides whether a particular security
solution is a good one.

Locks are a good example for this. It has a low cost/effect ratio, and very
easy to use. Is it 100% safe? Definitely not. People lock their bikes to a
tree when they enter a supermarket because it's reasonably safe. But leaving
their bikes like that over a few nights on a downtown street? Probably not a
good idea. Don't assume all people are idiots who do not know that (ok, some
people are, so the lock's manual states it can be bypassed by a skilled
thief).

But what tapes are good for? I don't know what kind of value it adds to the
discussion.

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linux-kernel-
 [EMAIL PROTECTED] On Behalf Of Pavel Machek
 Sent: Saturday, October 27, 2007 11:29 AM
 To: Ray Lee
 Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
 linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
 Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
 Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
 Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
 static interface)
 
 Hi!
 
The idea that poor security is worse than no security is
 fallacious,
and not backed up by common experience.
  
   There is a ton of evidence both in computing and outside of it
 which
   shows that poor security can be very much worse than no security at
 all.
 
  (So, I take it that you *don't* lock your bike up, as poor security
 is
  worse than none?)
 
 I do lock my bike with combination lock I found somewhere and cracked
 in five minutes... sometimes.
 
 But do you suggest that I use paper tape to 'lock' my bike to
 streetlight? You just said that poor security is better than none,
 right?
 
   Pavel
 --
 (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 [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Alan Cox wrote:
 The idea that poor security is worse than no security is fallacious,
 and not backed up by common experience.
 
 There is a ton of evidence both in computing and outside of it which
 shows that poor security can be very much worse than no security at all.
 In particular stuff which makes users think they are secure but is
 worthless is very dangerous indeed.

 When you know that security is limited you act appropriately, when you
 believe security is good but it is not you take inappropriate risks and
 get badly burned.
   
The bad security is worse than no security idea comes exactly from
what Alan says above: it happens when the security is not as good as you
think it is, and so you don't take adequate precautions.

Using the ongoing bicycle lock example, the discovery a few years ago
that a certain model of Kryptonite bike lock could be picked with a
simple pen made the security on this otherwise very sturdy lock become
abruptly very weak http://www.wired.com/culture/lifestyle/news/2004/09/64987

Conversely, the case can also be made that weak security is better than
no security. It is better to secure your bike with a $10 lock than no
lock. If someone insists on only high security bike locks that cost
$1000 and weigh 30 lbs, then most people will choose to not lock their
bikes, or skip biking all together.

IMHO, much of the criticism leveled at proposed LSMs has been of the
latter kind, or worse. That the security of the proposed LSM does not
meet some particular use case does not make it bad, it makes it not
for that use case.

To reject an LSM for providing bad security, IMHO you should have to
show how it is possible to subvert the self-stated goals of that LSM.
Complaints that the LSM fails to meet some goal outside of its stated
purpose is irrelevant. Conjecture that it probably can be violated
because of $contrivance is just so much FUD.

Exception: it is valid to say that the self-stated goal is too narrow to
be useful. But IMHO that bar of too narrow should be very, very low.
Defenses against specific modes of attack would be a fine thing to build
up in the library of LSMs, especially if we got a decent stacking module
so that they could be composed.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

 To reject an LSM for providing bad security, IMHO you should have to
 show how it is possible to subvert the self-stated goals of that LSM.
 Complaints that the LSM fails to meet some goal outside of its stated
 purpose is irrelevant. Conjecture that it probably can be violated
 because of $contrivance is just so much FUD.

That seems to be an appropriate test.

 Exception: it is valid to say that the self-stated goal is too narrow to
 be useful. But IMHO that bar of too narrow should be very, very low.
 Defenses against specific modes of attack would be a fine thing to build
 up in the library of LSMs, especially if we got a decent stacking module
 so that they could be composed.

Once you have stacking then it actually at times will make sense to have
security modules that do one very precise thing and do it well.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Dolding]

On 10/29/07, Crispin Cowan [EMAIL PROTECTED] wrote:
 To reject an LSM for providing bad security, IMHO you should have to
 show how it is possible to subvert the self-stated goals of that LSM.
 Complaints that the LSM fails to meet some goal outside of its stated
 purpose is irrelevant. Conjecture that it probably can be violated
 because of $contrivance is just so much FUD.

LSM is providing bad security on two fronts.

Number 1 LSM are speeding effort to create features.  Apparmor and
Selinux both provide file access filtering from applications.  Yet
they double up the code to do it.   So they cannot be used with each
other without doubling up hooks.  Then other LSM are creating there
own sections of code to do the same thing.   Simple rule more code
more risk of bugs since it will be less audited.  Duplication defense
features is really bad for security.  Some how code sharing has to be
got into LSM construction.

Number 2 The critical bit LSM stop at the edges of applications.   Now
without overlapping my hooks with existing LSMs I cannot create
application level protections.  Overlapping hooks will cause speed
loss.

LSM is set to protect the application. But inside the application
there will be sections that need the access rights and others that
don't.  Now a exploit in any section of the application under LSM gets
the LSM assigned rights.   With application level this can be done a
few ways extension to elf that is create by the complier and api calls
lowering access functions of current thread or for a starting thread.
If you exploit a section of the code without access to disk network
access and so on and without the right to call any function that does
that.   What have you exploited.   Minor data damage compared to
complete data that the application have access to being stolen as what
is the case with LSM at moment.  Basically LSM prevent taking control
of the complete system but don't help to stop peoples private data
from being stolen.  Both are bad to happen to a person.

LSM design is there to help security development not get in its way or
to cause bitrot.  Currently LSM design is causing major risk bitrot in
duplicated code.

Reading and processing configuration files should be independent to
the protection methods.   Hopefully designed to be able to run user
mode to test if the new profile for a application is safe to add
before adding it to the OS.   Typo prevention on both sides.  Current
method of just sticking everything into one huge blob is preventing
code sharing and risking more security holes.

The current LSM design is bad on so many levels.  I am surprised that
it takes a Non PHD System Admin to see it.  Some how I think its a
empire thing.   If everything was just simple blocks a person could
write a new LSM in hours with pretty good security.  Compared to
todays long time trying effort.  Leads of Apparmor selinux and so on
not being prepared to give up there little empire for the greater
good.

I personally hate stacking as a idea.  I personally prefer two layers
only.  Config reading and  enforcement.   Of course that does not stop
applications being assigned to different config reading systems.
Depth the two layers should stay fixed even if you have many different
models in use.

All LSM seam to want to force System Admins to pick there LSM over
another.   Instead of being able to pick LSM for task at hand.   Same
with poor security being better than no security its true.  Its
nothing strange to find selinux based systems with there security
disabled because the Admin cannot configure it.   But the reverse is
also true that when you have skilled Admins stuck with a system like
Apparmor cannot harden the system as far as they could with selinux.
Both ways its causing security holes poor security when you should
have good security is bad too.  Part of the problem LSM maintainers
are not at the front lines is all I can guess.  Because they don't
seam to know what is really needed.

Peter Dolding
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Arjan van de Ven]

On Sun, 28 Oct 2007 15:08:56 -0700
Crispin Cowan [EMAIL PROTECTED] wrote:

 To reject an LSM for providing bad security, IMHO you should have to
 show how it is possible to subvert the self-stated goals of that LSM.
 Complaints that the LSM fails to meet some goal outside of its stated
 purpose is irrelevant. Conjecture that it probably can be violated
 because of $contrivance is just so much FUD.

exactly; this is why I've been pushing recently for each new LSM to at
least document and make explicit what it tries to protect / protect
against (threat model and defense model in traditional security terms).
Without such an explicit description it's both impossible to
neutrally review a proposed LSM towards its goals, and it ends up as
a result with people making assumptions and attacking the model because
there's no separation between code and model.

 
 Exception: it is valid to say that the self-stated goal is too narrow
 to be useful. But IMHO that bar of too narrow should be very, very
 low. Defenses against specific modes of attack would be a fine thing
 to build up in the library of LSMs, especially if we got a decent
 stacking module so that they could be composed.

again I agree pretty much; I do want to reserve some minimum common
sense bar because people may (and probably will) do silly things withs
LSMs that are really not the right thing to do objectively.


-- 
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tetsuo Handa]

Hello.

Simon Arlott wrote:
> I currently have an LSM that only handles permissions for socket_bind
> and socket_listen, I load it and then "capability" as secondary on
> boot - but now I can't because the LSM framework is now just the LS
> framework.

I think there are two other problems regarding LSM.

(1) There is only one "struct security_ops" structure in the system.

(2) There is only one "void *security" field in "struct task_struct".


Years ago, there was only one MAC implementation (i.e. SELinux)
in the mainline kernel.
But now, there are many MAC (or access control/tracking) implementations
waiting for inclusion into the mainline kernel.
The competition for occupying "struct security_ops" has started.

My idea is that, why not create chains of "struct security_ops"
(i.e. linked list of "struct security_ops")
and allow choosing which chain to use for per a "struct task_struct" basis
(i.e. add "struct security_ops" to "struct task_struct").

TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
"struct security_ops" since SELinux is occupying it.
Yes, there is secondary_ops in SELinux, but it doesn't help TOMOYO Linux
since SELinux is not calling secondary ops for operations TOMOYO Linux wants to 
control.
So, there is only one "struct security_ops" as a matter of practice.


At the same time, the competition for occupying "void *security" has started.

My idea is that, why not allow multiple "void *security" fields in "struct 
task_struct"?

TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
"struct task_struct"->security field since SELinux is occupying it.
If TOMOYO Linux is permitted to add "void *" and "u32" to "struct task_struct",
SELinux and other LSM implementations can use "struct task_struct"->security 
field.


May be we should consider stackable LSM again?

Regards.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tetsuo Handa]

Hello.

Simon Arlott wrote:
 I currently have an LSM that only handles permissions for socket_bind
 and socket_listen, I load it and then capability as secondary on
 boot - but now I can't because the LSM framework is now just the LS
 framework.

I think there are two other problems regarding LSM.

(1) There is only one struct security_ops structure in the system.

(2) There is only one void *security field in struct task_struct.


Years ago, there was only one MAC implementation (i.e. SELinux)
in the mainline kernel.
But now, there are many MAC (or access control/tracking) implementations
waiting for inclusion into the mainline kernel.
The competition for occupying struct security_ops has started.

My idea is that, why not create chains of struct security_ops
(i.e. linked list of struct security_ops)
and allow choosing which chain to use for per a struct task_struct basis
(i.e. add struct security_ops to struct task_struct).

TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
struct security_ops since SELinux is occupying it.
Yes, there is secondary_ops in SELinux, but it doesn't help TOMOYO Linux
since SELinux is not calling secondary ops for operations TOMOYO Linux wants to 
control.
So, there is only one struct security_ops as a matter of practice.


At the same time, the competition for occupying void *security has started.

My idea is that, why not allow multiple void *security fields in struct 
task_struct?

TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
struct task_struct-security field since SELinux is occupying it.
If TOMOYO Linux is permitted to add void * and u32 to struct task_struct,
SELinux and other LSM implementations can use struct task_struct-security 
field.


May be we should consider stackable LSM again?

Regards.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Adrian Bunk]

On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> >> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> >> > Generally, the goal is to get external modules included into the kernel.
> >> > [...] even though it might sound harsh breaking
> >> > external modules and thereby making people aware that their code should 
> >> > get into the kernel is IMHO a positive point.
> >> 
> >> This argument seems to start from the assumption that any externally
> >> maintained kernel code *can* get into the kernel, which doesn't stand
> >> up to  reality. Once you admit that there is code which, for very good
> >> reasons, won't ever be accepted into the mainline kernel tree, what you
> >> are saying amounts to: "Code that isn't fit to be included in the
> >> mainline kernel isn't fit to exist at all."
> > 
> > What kind of code is not accepted into the mainline kernel tree for good
> > reasons?
> 
> - proprietary code

It's unclear whether distributing not GPL compatible modules is legal
at all.

And they are definitely not "very good reasons" for doing anything in 
the kernel.

> - unmaintained code

Unmaintained code in the kernel has a realistic chance of being usable 
for 5 years.

Unmaintained external code is quite likely to be unusable after
at most one year.

> - code conflicting with existing kernel structure or policy
> - code in which the concerned subsystem maintainers see no benefit

Let's fix the problems, not work around them.

There is a conflict between getting code included and ensuring some 
minimum quality of the kernel, but in many cases we could try better.

And when there's a good reason for a kernel policy, then code that
violates this policy is not a "very good reason" for anything.

> - code which its author is unable and/or unwilling to convert to
>   kernel coding standards
> - code whose author is unable and/or unwilling to defend it on LKML
>...

That's their fault, and definitely not a "very good reason" for making 
life easier for them.

> Thanks,
> Tilman

cu
Adrian

-- 

   "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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Simon Arlott]

On 26/10/07 16:58, Greg KH wrote:
> On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
>> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
>> > I'm trying to compile a list of all known external modules and drivers
>> > and work to get them included in the main kernel tree to help prevent
>> > these kinds of things.  If you know of any that are not on the list at:
>> >http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>> > please feel free to add them, or email me with the needed information
>> > and I will add them to the list.
>> 
>> That's certainly helpful, but I still think there will always be
>> a number of external modules that cannot be merged right now or at
>> all, and deliberately making life difficult for out-of-tree code
>> maintainers in order to coerce them into submitting their code for
>> inclusion in the kernel will not work, it'll only create bad
>> feelings.
> 
> Do you have examples of proof of this?  Read
> Documentation/stable_api_nonsense.txt for how we already make
> out-of-tree code developer's lives hell :)

The change makes it much harder to develop in tree too. Also, this really 
needs to be reverted and put in the feature removal schedule... unless 
you intend to deliberately make all out of tree LSMs unusable with no 
warning and no time to have them added to the kernel? We're already at 
2.6.24-rc1.

-- 
Simon Arlott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Greg KH]

On Fri, Oct 26, 2007 at 09:09:05AM +0200, Jan Engelhardt wrote:
> 
> On Oct 25 2007 19:56, Greg KH wrote:
> >
> >I'm trying to compile a list of all known external modules and drivers
> >and work to get them included in the main kernel tree to help prevent
> >these kinds of things.  If you know of any that are not on the list at:
> > http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> >please feel free to add them, or email me with the needed information
> >and I will add them to the list.
> 
> Do I have to at least try to submit it to LKML first before it is
> even considered for the OOT wiki page? :-)

No, you can go hide on your own, that's what the majority of projects on
that page have done :)

But of course, it would be good for you to at least submit it and get
feedback.  Or, if you don't want to do it, the linuxdriverproject
developers would be glad to help you out...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Greg KH]

On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > I'm trying to compile a list of all known external modules and drivers
> > and work to get them included in the main kernel tree to help prevent
> > these kinds of things.  If you know of any that are not on the list at:
> > http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> > please feel free to add them, or email me with the needed information
> > and I will add them to the list.
> 
> That's certainly helpful, but I still think there will always be
> a number of external modules that cannot be merged right now or at
> all, and deliberately making life difficult for out-of-tree code
> maintainers in order to coerce them into submitting their code for
> inclusion in the kernel will not work, it'll only create bad
> feelings.

Do you have examples of proof of this?  Read
Documentation/stable_api_nonsense.txt for how we already make
out-of-tree code developer's lives hell :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tilman Schmidt]

On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
>> Am 25.10.2007 00:31 schrieb Adrian Bunk:
>> > Generally, the goal is to get external modules included into the kernel.
>> > [...] even though it might sound harsh breaking
>> > external modules and thereby making people aware that their code should 
>> > get into the kernel is IMHO a positive point.
>> 
>> This argument seems to start from the assumption that any externally
>> maintained kernel code *can* get into the kernel, which doesn't stand
>> up to  reality. Once you admit that there is code which, for very good
>> reasons, won't ever be accepted into the mainline kernel tree, what you
>> are saying amounts to: "Code that isn't fit to be included in the
>> mainline kernel isn't fit to exist at all."
> 
> What kind of code is not accepted into the mainline kernel tree for good
> reasons?

- proprietary code
- unmaintained code
- code conflicting with existing kernel structure or policy
- code in which the concerned subsystem maintainers see no benefit
- code which its author is unable and/or unwilling to convert to
  kernel coding standards
- code whose author is unable and/or unwilling to defend it on LKML

> What are these reasons?

The details vary, but the fundamental reason is always the same: to
maintain a sufficient level of code quality in the kernel. Point in
case, the recent discussion whether drivers not supporting
suspend/resume should be refused to merge.

> What specific code are you talking about?

Some examples, in no particular order: Reiser4, AppArmor, VMware,
the staircase deadline scheduler, the first version of ser_gigaset,
the Matrox HAL module, SuSE's "taint extension". Yes, some of these
are in the kernel now, or have been superseded by other code that
is, but that doesn't invalidate my concern.

> I'm trying to compile a list of all known external modules and drivers
> and work to get them included in the main kernel tree to help prevent
> these kinds of things.  If you know of any that are not on the list at:
>   http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> please feel free to add them, or email me with the needed information
> and I will add them to the list.

That's certainly helpful, but I still think there will always be
a number of external modules that cannot be merged right now or at
all, and deliberately making life difficult for out-of-tree code
maintainers in order to coerce them into submitting their code for
inclusion in the kernel will not work, it'll only create bad
feelings.

Thanks,
Tilman

-- 
Tilman SchmidtE-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

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

[Jan Engelhardt]

On Oct 25 2007 19:56, Greg KH wrote:
>
>I'm trying to compile a list of all known external modules and drivers
>and work to get them included in the main kernel tree to help prevent
>these kinds of things.  If you know of any that are not on the list at:
>   http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>please feel free to add them, or email me with the needed information
>and I will add them to the list.

Do I have to at least try to submit it to LKML first before it is
even considered for the OOT wiki page? :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

On Oct 25 2007 19:56, Greg KH wrote:

I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things.  If you know of any that are not on the list at:
   http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
please feel free to add them, or email me with the needed information
and I will add them to the list.

Do I have to at least try to submit it to LKML first before it is
even considered for the OOT wiki page? :-)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tilman Schmidt]

On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
 On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
 Am 25.10.2007 00:31 schrieb Adrian Bunk:
  Generally, the goal is to get external modules included into the kernel.
  [...] even though it might sound harsh breaking
  external modules and thereby making people aware that their code should 
  get into the kernel is IMHO a positive point.
 
 This argument seems to start from the assumption that any externally
 maintained kernel code *can* get into the kernel, which doesn't stand
 up to  reality. Once you admit that there is code which, for very good
 reasons, won't ever be accepted into the mainline kernel tree, what you
 are saying amounts to: Code that isn't fit to be included in the
 mainline kernel isn't fit to exist at all.
 
 What kind of code is not accepted into the mainline kernel tree for good
 reasons?

- proprietary code
- unmaintained code
- code conflicting with existing kernel structure or policy
- code in which the concerned subsystem maintainers see no benefit
- code which its author is unable and/or unwilling to convert to
  kernel coding standards
- code whose author is unable and/or unwilling to defend it on LKML

 What are these reasons?

The details vary, but the fundamental reason is always the same: to
maintain a sufficient level of code quality in the kernel. Point in
case, the recent discussion whether drivers not supporting
suspend/resume should be refused to merge.

 What specific code are you talking about?

Some examples, in no particular order: Reiser4, AppArmor, VMware,
the staircase deadline scheduler, the first version of ser_gigaset,
the Matrox HAL module, SuSE's taint extension. Yes, some of these
are in the kernel now, or have been superseded by other code that
is, but that doesn't invalidate my concern.

 I'm trying to compile a list of all known external modules and drivers
 and work to get them included in the main kernel tree to help prevent
 these kinds of things.  If you know of any that are not on the list at:
   http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
 please feel free to add them, or email me with the needed information
 and I will add them to the list.

That's certainly helpful, but I still think there will always be
a number of external modules that cannot be merged right now or at
all, and deliberately making life difficult for out-of-tree code
maintainers in order to coerce them into submitting their code for
inclusion in the kernel will not work, it'll only create bad
feelings.

Thanks,
Tilman

-- 
Tilman SchmidtE-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

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

[Greg KH]

On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
 On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
  I'm trying to compile a list of all known external modules and drivers
  and work to get them included in the main kernel tree to help prevent
  these kinds of things.  If you know of any that are not on the list at:
  http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
  please feel free to add them, or email me with the needed information
  and I will add them to the list.
 
 That's certainly helpful, but I still think there will always be
 a number of external modules that cannot be merged right now or at
 all, and deliberately making life difficult for out-of-tree code
 maintainers in order to coerce them into submitting their code for
 inclusion in the kernel will not work, it'll only create bad
 feelings.

Do you have examples of proof of this?  Read
Documentation/stable_api_nonsense.txt for how we already make
out-of-tree code developer's lives hell :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Greg KH]

On Fri, Oct 26, 2007 at 09:09:05AM +0200, Jan Engelhardt wrote:
 
 On Oct 25 2007 19:56, Greg KH wrote:
 
 I'm trying to compile a list of all known external modules and drivers
 and work to get them included in the main kernel tree to help prevent
 these kinds of things.  If you know of any that are not on the list at:
  http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
 please feel free to add them, or email me with the needed information
 and I will add them to the list.
 
 Do I have to at least try to submit it to LKML first before it is
 even considered for the OOT wiki page? :-)

No, you can go hide on your own, that's what the majority of projects on
that page have done :)

But of course, it would be good for you to at least submit it and get
feedback.  Or, if you don't want to do it, the linuxdriverproject
developers would be glad to help you out...

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Simon Arlott]

On 26/10/07 16:58, Greg KH wrote:
 On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
 On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
  I'm trying to compile a list of all known external modules and drivers
  and work to get them included in the main kernel tree to help prevent
  these kinds of things.  If you know of any that are not on the list at:
 http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
  please feel free to add them, or email me with the needed information
  and I will add them to the list.
 
 That's certainly helpful, but I still think there will always be
 a number of external modules that cannot be merged right now or at
 all, and deliberately making life difficult for out-of-tree code
 maintainers in order to coerce them into submitting their code for
 inclusion in the kernel will not work, it'll only create bad
 feelings.
 
 Do you have examples of proof of this?  Read
 Documentation/stable_api_nonsense.txt for how we already make
 out-of-tree code developer's lives hell :)

The change makes it much harder to develop in tree too. Also, this really 
needs to be reverted and put in the feature removal schedule... unless 
you intend to deliberately make all out of tree LSMs unusable with no 
warning and no time to have them added to the kernel? We're already at 
2.6.24-rc1.

-- 
Simon Arlott
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Adrian Bunk]

On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
 On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
  On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
  Am 25.10.2007 00:31 schrieb Adrian Bunk:
   Generally, the goal is to get external modules included into the kernel.
   [...] even though it might sound harsh breaking
   external modules and thereby making people aware that their code should 
   get into the kernel is IMHO a positive point.
  
  This argument seems to start from the assumption that any externally
  maintained kernel code *can* get into the kernel, which doesn't stand
  up to  reality. Once you admit that there is code which, for very good
  reasons, won't ever be accepted into the mainline kernel tree, what you
  are saying amounts to: Code that isn't fit to be included in the
  mainline kernel isn't fit to exist at all.
  
  What kind of code is not accepted into the mainline kernel tree for good
  reasons?
 
 - proprietary code

It's unclear whether distributing not GPL compatible modules is legal
at all.

And they are definitely not very good reasons for doing anything in 
the kernel.

 - unmaintained code

Unmaintained code in the kernel has a realistic chance of being usable 
for 5 years.

Unmaintained external code is quite likely to be unusable after
at most one year.

 - code conflicting with existing kernel structure or policy
 - code in which the concerned subsystem maintainers see no benefit

Let's fix the problems, not work around them.

There is a conflict between getting code included and ensuring some 
minimum quality of the kernel, but in many cases we could try better.

And when there's a good reason for a kernel policy, then code that
violates this policy is not a very good reason for anything.

 - code which its author is unable and/or unwilling to convert to
   kernel coding standards
 - code whose author is unable and/or unwilling to defend it on LKML
...

That's their fault, and definitely not a very good reason for making 
life easier for them.

 Thanks,
 Tilman

cu
Adrian

-- 

   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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/