The price of SELinux (CPU)

The price of SELinux (CPU)

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've heard that SELinux has produced benchmarks such as 7% increased CPU
load.  Is this true and current?  Is it dependent on policy?  What is
the policy lookup complexity ( O(1), O(n), O(nlogn)...)?  Are there
other places where a bottleneck may exist aside from gruffing with the
policy?  Isn't the policy actually in xattrs so it's O(1)?  Where else
would an overhead that big come from aside from a lookup in a table?

....

Why is the sky blue?  Why do you have a mustach?  Why doesn't mommy have
one?  Does she shave it?

At any rate, my personal end goal is a secure high-performance operating
system, as user friendly as Ubuntu, Mandriva, or Win----.  To this end,
I'm (still; a lot of you have seen me before) evaluating the performance
hit of various user and kernel security enhancements like PaX,
ProPolice, various OpenWall/GrSecurity niceness that needs to be divided
out, and of course LSM/SELinux.  Also wondering about that PHKMalloc
thing on openbsd; is it really all that, is it junk, how's it compare to
the recent ptmalloc work, and can it run on Linux for direct benching .
. . but that's off topic.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDQgT4hDd4aOud5P8RAoWBAJ0foEe4JcqDDlb7mMXQ6Z6FjCFjLACfdmJz
+j2lCH7DpTlZK6zUztldEGI=
=RzhA
-----END PGP SIGNATURE-----

Re: The price of SELinux (CPU)

[Dan C Marinescu]

try selinux=0, _if u feel that way :-)

about big o:

http://www.maththinking.com/boat/compsciBooksIndex.html

   daniel



--- John Richard Moser <nigelenki@comcast.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've heard that SELinux has produced benchmarks such
> as 7% increased CPU
> load.  Is this true and current?  Is it dependent on
> policy?  What is
> the policy lookup complexity ( O(1), O(n),
> O(nlogn)...)?  Are there
> other places where a bottleneck may exist aside from
> gruffing with the
> policy?  Isn't the policy actually in xattrs so it's
> O(1)?  Where else
> would an overhead that big come from aside from a
> lookup in a table?
> 
> ....
> 
> Why is the sky blue?  Why do you have a mustach? 
> Why doesn't mommy have
> one?  Does she shave it?
> 
> At any rate, my personal end goal is a secure
> high-performance operating
> system, as user friendly as Ubuntu, Mandriva, or
> Win----.  To this end,
> I'm (still; a lot of you have seen me before)
> evaluating the performance
> hit of various user and kernel security enhancements
> like PaX,
> ProPolice, various OpenWall/GrSecurity niceness that
> needs to be divided
> out, and of course LSM/SELinux.  Also wondering
> about that PHKMalloc
> thing on openbsd; is it really all that, is it junk,
> how's it compare to
> the recent ptmalloc work, and can it run on Linux
> for direct benching .
> . . but that's off topic.
> 
> - --
> All content of all messages exchanged herein are
> left in the
> Public Domain, unless otherwise explicitly stated.
> 
>     Creative brains are a valuable, limited
> resource. They shouldn't be
>     wasted on re-inventing the wheel when there are
> so many fascinating
>     new problems waiting out there.
>                                                  --
> Eric Steven Raymond
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird -
> http://enigmail.mozdev.org
> 
>
iD8DBQFDQgT4hDd4aOud5P8RAoWBAJ0foEe4JcqDDlb7mMXQ6Z6FjCFjLACfdmJz
> +j2lCH7DpTlZK6zUztldEGI=
> =RzhA
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: The price of SELinux (CPU)

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not an abortionist; if I hear something has an ugly side, I try to
find out if it can be fixed, and if the trade-off is worth getting rid
of it.  SELinux and LSM are quite useful you know; the overhead is
probably not even that significant on the desktop to gamers (although if
you TELL them about it they'll piss themselves), from a practical
viewpoint considering their excessive hardware.

Dan C Marinescu wrote:
> try selinux=0, _if u feel that way :-)
> 
> about big o:
> 
> http://www.maththinking.com/boat/compsciBooksIndex.html
> 
>    daniel
> 
> 
> 
> --- John Richard Moser <nigelenki@comcast.net> wrote:
> 
> 
> I've heard that SELinux has produced benchmarks such
> as 7% increased CPU
> load.  Is this true and current?  Is it dependent on
> policy?  What is
> the policy lookup complexity ( O(1), O(n),
> O(nlogn)...)?  Are there
> other places where a bottleneck may exist aside from
> gruffing with the
> policy?  Isn't the policy actually in xattrs so it's
> O(1)?  Where else
> would an overhead that big come from aside from a
> lookup in a table?
> 
> ....
> 
> Why is the sky blue?  Why do you have a mustach? 
> Why doesn't mommy have
> one?  Does she shave it?
> 
> At any rate, my personal end goal is a secure
> high-performance operating
> system, as user friendly as Ubuntu, Mandriva, or
> Win----.  To this end,
> I'm (still; a lot of you have seen me before)
> evaluating the performance
> hit of various user and kernel security enhancements
> like PaX,
> ProPolice, various OpenWall/GrSecurity niceness that
> needs to be divided
> out, and of course LSM/SELinux.  Also wondering
> about that PHKMalloc
> thing on openbsd; is it really all that, is it junk,
> how's it compare to
> the recent ptmalloc work, and can it run on Linux
> for direct benching .
> . . but that's off topic.
> 
> --
> All content of all messages exchanged herein are
> left in the
> Public Domain, unless otherwise explicitly stated.
> 
>     Creative brains are a valuable, limited
> resource. They shouldn't be
>     wasted on re-inventing the wheel when there are
> so many fascinating
>     new problems waiting out there.
>                                                  --
> Eric Steven Raymond
- -
To unsubscribe from this list: send the line
"unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

> __________________________________ 
> Yahoo! Mail - PC Magazine Editors' Choice 2005 
> http://mail.yahoo.com


- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDQgwahDd4aOud5P8RArHEAJ9GFTpKPX3BbAR9vF/UCxeqbXO8DQCgi3sC
R8bKVy1wxP2SiGJyc0MB4Xw=
=vvMx
-----END PGP SIGNATURE-----

Re: The price of SELinux (CPU)

[Dan C Marinescu]

i suggested you to disable selinux in order to have
something to compare to... (engineers compare,
measure, instead of believing in rummors...)

   d

--- John Richard Moser <nigelenki@comcast.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm not an abortionist; if I hear something has an
> ugly side, I try to
> find out if it can be fixed, and if the trade-off is
> worth getting rid
> of it.  SELinux and LSM are quite useful you know;
> the overhead is
> probably not even that significant on the desktop to
> gamers (although if
> you TELL them about it they'll piss themselves),
> from a practical
> viewpoint considering their excessive hardware.
> 
> Dan C Marinescu wrote:
> > try selinux=0, _if u feel that way :-)
> > 
> > about big o:
> > 
> >
>
http://www.maththinking.com/boat/compsciBooksIndex.html
> > 
> >    daniel
> > 
> > 
> > 
> > --- John Richard Moser <nigelenki@comcast.net>
> wrote:
> > 
> > 
> > I've heard that SELinux has produced benchmarks
> such
> > as 7% increased CPU
> > load.  Is this true and current?  Is it dependent
> on
> > policy?  What is
> > the policy lookup complexity ( O(1), O(n),
> > O(nlogn)...)?  Are there
> > other places where a bottleneck may exist aside
> from
> > gruffing with the
> > policy?  Isn't the policy actually in xattrs so
> it's
> > O(1)?  Where else
> > would an overhead that big come from aside from a
> > lookup in a table?
> > 
> > ....
> > 
> > Why is the sky blue?  Why do you have a mustach? 
> > Why doesn't mommy have
> > one?  Does she shave it?
> > 
> > At any rate, my personal end goal is a secure
> > high-performance operating
> > system, as user friendly as Ubuntu, Mandriva, or
> > Win----.  To this end,
> > I'm (still; a lot of you have seen me before)
> > evaluating the performance
> > hit of various user and kernel security
> enhancements
> > like PaX,
> > ProPolice, various OpenWall/GrSecurity niceness
> that
> > needs to be divided
> > out, and of course LSM/SELinux.  Also wondering
> > about that PHKMalloc
> > thing on openbsd; is it really all that, is it
> junk,
> > how's it compare to
> > the recent ptmalloc work, and can it run on Linux
> > for direct benching .
> > . . but that's off topic.
> > 
> > --
> > All content of all messages exchanged herein are
> > left in the
> > Public Domain, unless otherwise explicitly stated.
> > 
> >     Creative brains are a valuable, limited
> > resource. They shouldn't be
> >     wasted on re-inventing the wheel when there
> are
> > so many fascinating
> >     new problems waiting out there.
> >                                                 
> --
> > Eric Steven Raymond
> - -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> > __________________________________ 
> > Yahoo! Mail - PC Magazine Editors' Choice 2005 
> > http://mail.yahoo.com
> 
> 
> - --
> All content of all messages exchanged herein are
> left in the
> Public Domain, unless otherwise explicitly stated.
> 
>     Creative brains are a valuable, limited
> resource. They shouldn't be
>     wasted on re-inventing the wheel when there are
> so many fascinating
>     new problems waiting out there.
>                                                  --
> Eric Steven Raymond
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird -
> http://enigmail.mozdev.org
> 
>
iD8DBQFDQgwahDd4aOud5P8RArHEAJ9GFTpKPX3BbAR9vF/UCxeqbXO8DQCgi3sC
> R8bKVy1wxP2SiGJyc0MB4Xw=
> =vvMx
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: The price of SELinux (CPU)

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not an expert in this kind of stuff.  I wonder where the numbers
come from; i.e. is 7% from policy?  A O(1) policy lookup would be immune
to big policies; a O(n) would probably not have that much impact from a
typical policy lookup.  Still perhaps interpreting the policy is a chore
in itself, which still says bigger policy means bigger hit.  Or is 7%
constant?

I don't know what the frame of reference is or was.  I'm sure with
selinux with no policy it's rather 0ish; what I don't know is what I'm
supposed to be looking at for benchmarking.  Just randomly turning
SELinux on and off and looking might give me an invalid measure.

Dan C Marinescu wrote:
> i suggested you to disable selinux in order to have
> something to compare to... (engineers compare,
> measure, instead of believing in rummors...)
> 
>    d
> 
> --- John Richard Moser <nigelenki@comcast.net> wrote:
> 
> 
> I'm not an abortionist; if I hear something has an
> ugly side, I try to
> find out if it can be fixed, and if the trade-off is
> worth getting rid
> of it.  SELinux and LSM are quite useful you know;
> the overhead is
> probably not even that significant on the desktop to
> gamers (although if
> you TELL them about it they'll piss themselves),
> from a practical
> viewpoint considering their excessive hardware.
> 
> Dan C Marinescu wrote:
> 
>>try selinux=0, _if u feel that way :-)
> 
>>about big o:
> 
> 
> 
>> http://www.maththinking.com/boat/compsciBooksIndex.html
> 
>>   daniel
> 
> 
> 
>>--- John Richard Moser <nigelenki@comcast.net>
> 
> wrote:
> 
> 
>>I've heard that SELinux has produced benchmarks
> 
> such
> 
>>as 7% increased CPU
>>load.  Is this true and current?  Is it dependent
> 
> on
> 
>>policy?  What is
>>the policy lookup complexity ( O(1), O(n),
>>O(nlogn)...)?  Are there
>>other places where a bottleneck may exist aside
> 
> from
> 
>>gruffing with the
>>policy?  Isn't the policy actually in xattrs so
> 
> it's
> 
>>O(1)?  Where else
>>would an overhead that big come from aside from a
>>lookup in a table?
> 
>>....
> 
>>Why is the sky blue?  Why do you have a mustach? 
>>Why doesn't mommy have
>>one?  Does she shave it?
> 
>>At any rate, my personal end goal is a secure
>>high-performance operating
>>system, as user friendly as Ubuntu, Mandriva, or
>>Win----.  To this end,
>>I'm (still; a lot of you have seen me before)
>>evaluating the performance
>>hit of various user and kernel security
> 
> enhancements
> 
>>like PaX,
>>ProPolice, various OpenWall/GrSecurity niceness
> 
> that
> 
>>needs to be divided
>>out, and of course LSM/SELinux.  Also wondering
>>about that PHKMalloc
>>thing on openbsd; is it really all that, is it
> 
> junk,
> 
>>how's it compare to
>>the recent ptmalloc work, and can it run on Linux
>>for direct benching .
>>. . but that's off topic.
> 
>>--
>>All content of all messages exchanged herein are
>>left in the
>>Public Domain, unless otherwise explicitly stated.
> 
>>    Creative brains are a valuable, limited
>>resource. They shouldn't be
>>    wasted on re-inventing the wheel when there
> 
> are
> 
>>so many fascinating
>>    new problems waiting out there.
> 
> 
> --
> 
>>Eric Steven Raymond
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
>>__________________________________ 
>>Yahoo! Mail - PC Magazine Editors' Choice 2005 
>>http://mail.yahoo.com
> 
> 
> --
> All content of all messages exchanged herein are
> left in the
> Public Domain, unless otherwise explicitly stated.
> 
>     Creative brains are a valuable, limited
> resource. They shouldn't be
>     wasted on re-inventing the wheel when there are
> so many fascinating
>     new problems waiting out there.
>                                                  --
> Eric Steven Raymond
- -
To unsubscribe from this list: send the line
"unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

> __________________________________ 
> Yahoo! Mail - PC Magazine Editors' Choice 2005 
> http://mail.yahoo.com


- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDQh9FhDd4aOud5P8RAt30AJ9Tj2VZJwWh8EfzPocOcTkAIY/kOACfe03m
wwtaci0G/aXWXok9NiWJR8E=
=78tr
-----END PGP SIGNATURE-----

Re: The price of SELinux (CPU)

[Dan C Marinescu]

for me, that 7% is about the price of tea in china...
:-)
have no clue...

   d

--- John Richard Moser <nigelenki@comcast.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm not an expert in this kind of stuff.  I wonder
> where the numbers
> come from; i.e. is 7% from policy?  A O(1) policy
> lookup would be immune
> to big policies; a O(n) would probably not have that
> much impact from a
> typical policy lookup.  Still perhaps interpreting
> the policy is a chore
> in itself, which still says bigger policy means
> bigger hit.  Or is 7%
> constant?
> 
> I don't know what the frame of reference is or was. 
> I'm sure with
> selinux with no policy it's rather 0ish; what I
> don't know is what I'm
> supposed to be looking at for benchmarking.  Just
> randomly turning
> SELinux on and off and looking might give me an
> invalid measure.
> 
> Dan C Marinescu wrote:
> > i suggested you to disable selinux in order to
> have
> > something to compare to... (engineers compare,
> > measure, instead of believing in rummors...)
> > 
> >    d
> > 
> > --- John Richard Moser <nigelenki@comcast.net>
> wrote:
> > 
> > 
> > I'm not an abortionist; if I hear something has an
> > ugly side, I try to
> > find out if it can be fixed, and if the trade-off
> is
> > worth getting rid
> > of it.  SELinux and LSM are quite useful you know;
> > the overhead is
> > probably not even that significant on the desktop
> to
> > gamers (although if
> > you TELL them about it they'll piss themselves),
> > from a practical
> > viewpoint considering their excessive hardware.
> > 
> > Dan C Marinescu wrote:
> > 
> >>try selinux=0, _if u feel that way :-)
> > 
> >>about big o:
> > 
> > 
> > 
> >>
>
http://www.maththinking.com/boat/compsciBooksIndex.html
> > 
> >>   daniel
> > 
> > 
> > 
> >>--- John Richard Moser <nigelenki@comcast.net>
> > 
> > wrote:
> > 
> > 
> >>I've heard that SELinux has produced benchmarks
> > 
> > such
> > 
> >>as 7% increased CPU
> >>load.  Is this true and current?  Is it dependent
> > 
> > on
> > 
> >>policy?  What is
> >>the policy lookup complexity ( O(1), O(n),
> >>O(nlogn)...)?  Are there
> >>other places where a bottleneck may exist aside
> > 
> > from
> > 
> >>gruffing with the
> >>policy?  Isn't the policy actually in xattrs so
> > 
> > it's
> > 
> >>O(1)?  Where else
> >>would an overhead that big come from aside from a
> >>lookup in a table?
> > 
> >>....
> > 
> >>Why is the sky blue?  Why do you have a mustach? 
> >>Why doesn't mommy have
> >>one?  Does she shave it?
> > 
> >>At any rate, my personal end goal is a secure
> >>high-performance operating
> >>system, as user friendly as Ubuntu, Mandriva, or
> >>Win----.  To this end,
> >>I'm (still; a lot of you have seen me before)
> >>evaluating the performance
> >>hit of various user and kernel security
> > 
> > enhancements
> > 
> >>like PaX,
> >>ProPolice, various OpenWall/GrSecurity niceness
> > 
> > that
> > 
> >>needs to be divided
> >>out, and of course LSM/SELinux.  Also wondering
> >>about that PHKMalloc
> >>thing on openbsd; is it really all that, is it
> > 
> > junk,
> > 
> >>how's it compare to
> >>the recent ptmalloc work, and can it run on Linux
> >>for direct benching .
> >>. . but that's off topic.
> > 
> >>--
> >>All content of all messages exchanged herein are
> >>left in the
> >>Public Domain, unless otherwise explicitly stated.
> > 
> >>    Creative brains are a valuable, limited
> >>resource. They shouldn't be
> >>    wasted on re-inventing the wheel when there
> > 
> > are
> > 
> >>so many fascinating
> >>    new problems waiting out there.
> > 
> > 
> > --
> > 
> >>Eric Steven Raymond
> > 
> > -
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
> >>__________________________________ 
> >>Yahoo! Mail - PC Magazine Editors' Choice 2005 
> >>http://mail.yahoo.com
> > 
> > 
> > --
> > All content of all messages exchanged herein are
> > left in the
> > Public Domain, unless otherwise explicitly stated.
> > 
> >     Creative brains are a valuable, limited
> > resource. They shouldn't be
> >     wasted on re-inventing the wheel when there
> are
> > so many fascinating
> >     new problems waiting out there.
> >                                                 
> --
> > Eric Steven Raymond
> - -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> > __________________________________ 
> > Yahoo! Mail - PC Magazine Editors' Choice 2005 
> > http://mail.yahoo.com
> 
> 
> - --
> All content of all messages exchanged herein are
> left in the
> Public Domain, unless otherwise explicitly stated.
> 
>     Creative brains are a valuable, limited
> resource. They shouldn't be
>     wasted on re-inventing the wheel when there are
> so many fascinating
>     new problems waiting out there.
>                                                  --
> Eric Steven Raymond
> -----BEGIN PGP SIGNATURE-----
> 
=== message truncated ===



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: The price of SELinux (CPU)

[Dan C Marinescu]

my answer is "does not compute, insuficient data"

this is like saying "light travels fast but there is a
7% trajectory distortion in certain conditions"...

*** it _depends_ on so many factors... the answer
_may_ be somewhere in fs, look at the source... etc...

i would rathere doubt the source... (tell me it's
slashdot or msdn or something :-)

    d

--- John Richard Moser <nigelenki@comcast.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm not an expert in this kind of stuff.  I wonder
> where the numbers
> come from; i.e. is 7% from policy?  A O(1) policy
> lookup would be immune
> to big policies; a O(n) would probably not have that
> much impact from a
> typical policy lookup.  Still perhaps interpreting
> the policy is a chore
> in itself, which still says bigger policy means
> bigger hit.  Or is 7%
> constant?
> 
> I don't know what the frame of reference is or was. 
> I'm sure with
> selinux with no policy it's rather 0ish; what I
> don't know is what I'm
> supposed to be looking at for benchmarking.  Just
> randomly turning
> SELinux on and off and looking might give me an
> invalid measure.
> 
> Dan C Marinescu wrote:
> > i suggested you to disable selinux in order to
> have
> > something to compare to... (engineers compare,
> > measure, instead of believing in rummors...)
> > 
> >    d
> > 
> > --- John Richard Moser <nigelenki@comcast.net>
> wrote:
> > 
> > 
> > I'm not an abortionist; if I hear something has an
> > ugly side, I try to
> > find out if it can be fixed, and if the trade-off
> is
> > worth getting rid
> > of it.  SELinux and LSM are quite useful you know;
> > the overhead is
> > probably not even that significant on the desktop
> to
> > gamers (although if
> > you TELL them about it they'll piss themselves),
> > from a practical
> > viewpoint considering their excessive hardware.
> > 
> > Dan C Marinescu wrote:
> > 
> >>try selinux=0, _if u feel that way :-)
> > 
> >>about big o:
> > 
> > 
> > 
> >>
>
http://www.maththinking.com/boat/compsciBooksIndex.html
> > 
> >>   daniel
> > 
> > 
> > 
> >>--- John Richard Moser <nigelenki@comcast.net>
> > 
> > wrote:
> > 
> > 
> >>I've heard that SELinux has produced benchmarks
> > 
> > such
> > 
> >>as 7% increased CPU
> >>load.  Is this true and current?  Is it dependent
> > 
> > on
> > 
> >>policy?  What is
> >>the policy lookup complexity ( O(1), O(n),
> >>O(nlogn)...)?  Are there
> >>other places where a bottleneck may exist aside
> > 
> > from
> > 
> >>gruffing with the
> >>policy?  Isn't the policy actually in xattrs so
> > 
> > it's
> > 
> >>O(1)?  Where else
> >>would an overhead that big come from aside from a
> >>lookup in a table?
> > 
> >>....
> > 
> >>Why is the sky blue?  Why do you have a mustach? 
> >>Why doesn't mommy have
> >>one?  Does she shave it?
> > 
> >>At any rate, my personal end goal is a secure
> >>high-performance operating
> >>system, as user friendly as Ubuntu, Mandriva, or
> >>Win----.  To this end,
> >>I'm (still; a lot of you have seen me before)
> >>evaluating the performance
> >>hit of various user and kernel security
> > 
> > enhancements
> > 
> >>like PaX,
> >>ProPolice, various OpenWall/GrSecurity niceness
> > 
> > that
> > 
> >>needs to be divided
> >>out, and of course LSM/SELinux.  Also wondering
> >>about that PHKMalloc
> >>thing on openbsd; is it really all that, is it
> > 
> > junk,
> > 
> >>how's it compare to
> >>the recent ptmalloc work, and can it run on Linux
> >>for direct benching .
> >>. . but that's off topic.
> > 
> >>--
> >>All content of all messages exchanged herein are
> >>left in the
> >>Public Domain, unless otherwise explicitly stated.
> > 
> >>    Creative brains are a valuable, limited
> >>resource. They shouldn't be
> >>    wasted on re-inventing the wheel when there
> > 
> > are
> > 
> >>so many fascinating
> >>    new problems waiting out there.
> > 
> > 
> > --
> > 
> >>Eric Steven Raymond
> > 
> > -
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
> >>__________________________________ 
> >>Yahoo! Mail - PC Magazine Editors' Choice 2005 
> >>http://mail.yahoo.com
> > 
> > 
> > --
> > All content of all messages exchanged herein are
> > left in the
> > Public Domain, unless otherwise explicitly stated.
> > 
> >     Creative brains are a valuable, limited
> > resource. They shouldn't be
> >     wasted on re-inventing the wheel when there
> are
> > so many fascinating
> >     new problems waiting out there.
> >                                                 
> --
> > Eric Steven Raymond
> - -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> > __________________________________ 
> > Yahoo! Mail - PC Magazine Editors' Choice 2005 
> > http://mail.yahoo.com
> 
> 
> - --
> All content of all messages exchanged herein are
> left in the
> Public Domain, unless otherwise explicitly stated.
> 
>     Creative brains are a valuable, limited
> resource. They shouldn't be
>     wasted on re-inventing the wheel when there are
> so many fascinating
>     new problems waiting out there.
>                                                  --
> Eric Steven Raymond
> -----BEGIN PGP SIGNATURE-----
> 
=== message truncated ===



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: The price of SELinux (CPU)

[Dan C Marinescu]

John,

Try this link:

http://www.nsa.gov/selinux/list-archive/0505/11459.cfm

It's from NSA... Hope this helps somehow...

   Daniel


--- John Richard Moser <nigelenki@comcast.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm not an expert in this kind of stuff.  I wonder
> where the numbers
> come from; i.e. is 7% from policy?  A O(1) policy
> lookup would be immune
> to big policies; a O(n) would probably not have that
> much impact from a
> typical policy lookup.  Still perhaps interpreting
> the policy is a chore
> in itself, which still says bigger policy means
> bigger hit.  Or is 7%
> constant?
> 
> I don't know what the frame of reference is or was. 
> I'm sure with
> selinux with no policy it's rather 0ish; what I
> don't know is what I'm
> supposed to be looking at for benchmarking.  Just
> randomly turning
> SELinux on and off and looking might give me an
> invalid measure.
> 
> Dan C Marinescu wrote:
> > i suggested you to disable selinux in order to
> have
> > something to compare to... (engineers compare,
> > measure, instead of believing in rummors...)
> > 
> >    d
> > 
> > --- John Richard Moser <nigelenki@comcast.net>
> wrote:
> > 
> > 
> > I'm not an abortionist; if I hear something has an
> > ugly side, I try to
> > find out if it can be fixed, and if the trade-off
> is
> > worth getting rid
> > of it.  SELinux and LSM are quite useful you know;
> > the overhead is
> > probably not even that significant on the desktop
> to
> > gamers (although if
> > you TELL them about it they'll piss themselves),
> > from a practical
> > viewpoint considering their excessive hardware.
> > 
> > Dan C Marinescu wrote:
> > 
> >>try selinux=0, _if u feel that way :-)
> > 
> >>about big o:
> > 
> > 
> > 
> >>
>
http://www.maththinking.com/boat/compsciBooksIndex.html
> > 
> >>   daniel
> > 
> > 
> > 
> >>--- John Richard Moser <nigelenki@comcast.net>
> > 
> > wrote:
> > 
> > 
> >>I've heard that SELinux has produced benchmarks
> > 
> > such
> > 
> >>as 7% increased CPU
> >>load.  Is this true and current?  Is it dependent
> > 
> > on
> > 
> >>policy?  What is
> >>the policy lookup complexity ( O(1), O(n),
> >>O(nlogn)...)?  Are there
> >>other places where a bottleneck may exist aside
> > 
> > from
> > 
> >>gruffing with the
> >>policy?  Isn't the policy actually in xattrs so
> > 
> > it's
> > 
> >>O(1)?  Where else
> >>would an overhead that big come from aside from a
> >>lookup in a table?
> > 
> >>....
> > 
> >>Why is the sky blue?  Why do you have a mustach? 
> >>Why doesn't mommy have
> >>one?  Does she shave it?
> > 
> >>At any rate, my personal end goal is a secure
> >>high-performance operating
> >>system, as user friendly as Ubuntu, Mandriva, or
> >>Win----.  To this end,
> >>I'm (still; a lot of you have seen me before)
> >>evaluating the performance
> >>hit of various user and kernel security
> > 
> > enhancements
> > 
> >>like PaX,
> >>ProPolice, various OpenWall/GrSecurity niceness
> > 
> > that
> > 
> >>needs to be divided
> >>out, and of course LSM/SELinux.  Also wondering
> >>about that PHKMalloc
> >>thing on openbsd; is it really all that, is it
> > 
> > junk,
> > 
> >>how's it compare to
> >>the recent ptmalloc work, and can it run on Linux
> >>for direct benching .
> >>. . but that's off topic.
> > 
> >>--
> >>All content of all messages exchanged herein are
> >>left in the
> >>Public Domain, unless otherwise explicitly stated.
> > 
> >>    Creative brains are a valuable, limited
> >>resource. They shouldn't be
> >>    wasted on re-inventing the wheel when there
> > 
> > are
> > 
> >>so many fascinating
> >>    new problems waiting out there.
> > 
> > 
> > --
> > 
> >>Eric Steven Raymond
> > 
> > -
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
> >>__________________________________ 
> >>Yahoo! Mail - PC Magazine Editors' Choice 2005 
> >>http://mail.yahoo.com
> > 
> > 
> > --
> > All content of all messages exchanged herein are
> > left in the
> > Public Domain, unless otherwise explicitly stated.
> > 
> >     Creative brains are a valuable, limited
> > resource. They shouldn't be
> >     wasted on re-inventing the wheel when there
> are
> > so many fascinating
> >     new problems waiting out there.
> >                                                 
> --
> > Eric Steven Raymond
> - -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> > __________________________________ 
> > Yahoo! Mail - PC Magazine Editors' Choice 2005 
> > http://mail.yahoo.com
> 
> 
> - --
> All content of all messages exchanged herein are
> left in the
> Public Domain, unless otherwise explicitly stated.
> 
>     Creative brains are a valuable, limited
> resource. They shouldn't be
>     wasted on re-inventing the wheel when there are
> so many fascinating
>     new problems waiting out there.
>                                                  --
> Eric Steven Raymond
> -----BEGIN PGP SIGNATURE-----
> 
=== message truncated ===



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: The price of SELinux (CPU)

[serue]

Quoting Dan C Marinescu (dan_c_marinescu@yahoo.com):
> John,
> 
> Try this link:
> 
> http://www.nsa.gov/selinux/list-archive/0505/11459.cfm
> 
> It's from NSA... Hope this helps somehow...

Note that these benchmarks were done quite some time ago.  Among
many other changes, selinux's memory overhead was recently significantly
reduced which should help these benchmarks quite a bit.

Hopefully we can do another round of benchmarks soon, but we were
waiting for particular machine to become available.

-serge

Re: The price of SELinux (CPU)

[Dan C Marinescu]

the following link:

http://www.nsa.gov/selinux/list-archive/0505/11459.cfm

describes _some_ particular cases... among the over
100,000,000,000 factors involved are:

1. fs type (block-size, etc) // not sure on this one
:-(
2. number of processors
3. nature of processes // they are relatively vague on
this one
4. kernel configuration (they mentioned about
2.6.12-rc2 or something) but then again, they didn't
post their kernel .config (maybe it's a fedora stock
.config, maybe not...)
...
...
...
etc

And even then, to draw the line at 7% sounds more like
a quick and dirty conclusion (@ least 2 me)... 

   d

--- John Richard Moser <nigelenki@comcast.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm not an expert in this kind of stuff.  I wonder
> where the numbers
> come from; i.e. is 7% from policy?  A O(1) policy
> lookup would be immune
> to big policies; a O(n) would probably not have that
> much impact from a
> typical policy lookup.  Still perhaps interpreting
> the policy is a chore
> in itself, which still says bigger policy means
> bigger hit.  Or is 7%
> constant?
> 
> I don't know what the frame of reference is or was. 
> I'm sure with
> selinux with no policy it's rather 0ish; what I
> don't know is what I'm
> supposed to be looking at for benchmarking.  Just
> randomly turning
> SELinux on and off and looking might give me an
> invalid measure.
> 
> Dan C Marinescu wrote:
> > i suggested you to disable selinux in order to
> have
> > something to compare to... (engineers compare,
> > measure, instead of believing in rummors...)
> > 
> >    d
> > 
> > --- John Richard Moser <nigelenki@comcast.net>
> wrote:
> > 
> > 
> > I'm not an abortionist; if I hear something has an
> > ugly side, I try to
> > find out if it can be fixed, and if the trade-off
> is
> > worth getting rid
> > of it.  SELinux and LSM are quite useful you know;
> > the overhead is
> > probably not even that significant on the desktop
> to
> > gamers (although if
> > you TELL them about it they'll piss themselves),
> > from a practical
> > viewpoint considering their excessive hardware.
> > 
> > Dan C Marinescu wrote:
> > 
> >>try selinux=0, _if u feel that way :-)
> > 
> >>about big o:
> > 
> > 
> > 
> >>
>
http://www.maththinking.com/boat/compsciBooksIndex.html
> > 
> >>   daniel
> > 
> > 
> > 
> >>--- John Richard Moser <nigelenki@comcast.net>
> > 
> > wrote:
> > 
> > 
> >>I've heard that SELinux has produced benchmarks
> > 
> > such
> > 
> >>as 7% increased CPU
> >>load.  Is this true and current?  Is it dependent
> > 
> > on
> > 
> >>policy?  What is
> >>the policy lookup complexity ( O(1), O(n),
> >>O(nlogn)...)?  Are there
> >>other places where a bottleneck may exist aside
> > 
> > from
> > 
> >>gruffing with the
> >>policy?  Isn't the policy actually in xattrs so
> > 
> > it's
> > 
> >>O(1)?  Where else
> >>would an overhead that big come from aside from a
> >>lookup in a table?
> > 
> >>....
> > 
> >>Why is the sky blue?  Why do you have a mustach? 
> >>Why doesn't mommy have
> >>one?  Does she shave it?
> > 
> >>At any rate, my personal end goal is a secure
> >>high-performance operating
> >>system, as user friendly as Ubuntu, Mandriva, or
> >>Win----.  To this end,
> >>I'm (still; a lot of you have seen me before)
> >>evaluating the performance
> >>hit of various user and kernel security
> > 
> > enhancements
> > 
> >>like PaX,
> >>ProPolice, various OpenWall/GrSecurity niceness
> > 
> > that
> > 
> >>needs to be divided
> >>out, and of course LSM/SELinux.  Also wondering
> >>about that PHKMalloc
> >>thing on openbsd; is it really all that, is it
> > 
> > junk,
> > 
> >>how's it compare to
> >>the recent ptmalloc work, and can it run on Linux
> >>for direct benching .
> >>. . but that's off topic.
> > 
> >>--
> >>All content of all messages exchanged herein are
> >>left in the
> >>Public Domain, unless otherwise explicitly stated.
> > 
> >>    Creative brains are a valuable, limited
> >>resource. They shouldn't be
> >>    wasted on re-inventing the wheel when there
> > 
> > are
> > 
> >>so many fascinating
> >>    new problems waiting out there.
> > 
> > 
> > --
> > 
> >>Eric Steven Raymond
> > 
> > -
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
> >>__________________________________ 
> >>Yahoo! Mail - PC Magazine Editors' Choice 2005 
> >>http://mail.yahoo.com
> > 
> > 
> > --
> > All content of all messages exchanged herein are
> > left in the
> > Public Domain, unless otherwise explicitly stated.
> > 
> >     Creative brains are a valuable, limited
> > resource. They shouldn't be
> >     wasted on re-inventing the wheel when there
> are
> > so many fascinating
> >     new problems waiting out there.
> >                                                 
> --
> > Eric Steven Raymond
> - -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> > __________________________________ 
> > Yahoo! Mail - PC Magazine Editors' Choice 2005 
> > http://mail.yahoo.com
> 
> 
> - --
> All content of all messages exchanged herein are
> left in the
> Public Domain, unless otherwise explicitly stated.
> 
>     Creative brains are a valuable, limited
> resource. They shouldn't be
>     wasted on re-inventing the wheel when there are
> so many fascinating
>     new problems waiting out there.
>                                                  --
> Eric Steven Raymond
> -----BEGIN PGP SIGNATURE-----
> 
=== message truncated ===



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: The price of SELinux (CPU)

[Dan C Marinescu]

the benchmark "results" _look_ like being authored by
some qa engineers... or sysadmins or something...

*** only a deep/intimate knowledge of kernel and fs
and acl implementation details and many other areas
could suggest a credible conclusion (most likely
without even needing any "profiling" at all... on pure
theoretical basis, mostly because you would know what
goes where and when and how and why and how much it
adds here and there, etc, etc, etc)

and i personally have a strong doubt that if the cpu
activity was statistically increased with 7% for the
very same elementary I/O, linus would have accepted
this degradation... my $0.02... :-)

   d

--- John Richard Moser <nigelenki@comcast.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm not an expert in this kind of stuff.  I wonder
> where the numbers
> come from; i.e. is 7% from policy?  A O(1) policy
> lookup would be immune
> to big policies; a O(n) would probably not have that
> much impact from a
> typical policy lookup.  Still perhaps interpreting
> the policy is a chore
> in itself, which still says bigger policy means
> bigger hit.  Or is 7%
> constant?
> 
> I don't know what the frame of reference is or was. 
> I'm sure with
> selinux with no policy it's rather 0ish; what I
> don't know is what I'm
> supposed to be looking at for benchmarking.  Just
> randomly turning
> SELinux on and off and looking might give me an
> invalid measure.
> 
> Dan C Marinescu wrote:
> > i suggested you to disable selinux in order to
> have
> > something to compare to... (engineers compare,
> > measure, instead of believing in rummors...)
> > 
> >    d
> > 
> > --- John Richard Moser <nigelenki@comcast.net>
> wrote:
> > 
> > 
> > I'm not an abortionist; if I hear something has an
> > ugly side, I try to
> > find out if it can be fixed, and if the trade-off
> is
> > worth getting rid
> > of it.  SELinux and LSM are quite useful you know;
> > the overhead is
> > probably not even that significant on the desktop
> to
> > gamers (although if
> > you TELL them about it they'll piss themselves),
> > from a practical
> > viewpoint considering their excessive hardware.
> > 
> > Dan C Marinescu wrote:
> > 
> >>try selinux=0, _if u feel that way :-)
> > 
> >>about big o:
> > 
> > 
> > 
> >>
>
http://www.maththinking.com/boat/compsciBooksIndex.html
> > 
> >>   daniel
> > 
> > 
> > 
> >>--- John Richard Moser <nigelenki@comcast.net>
> > 
> > wrote:
> > 
> > 
> >>I've heard that SELinux has produced benchmarks
> > 
> > such
> > 
> >>as 7% increased CPU
> >>load.  Is this true and current?  Is it dependent
> > 
> > on
> > 
> >>policy?  What is
> >>the policy lookup complexity ( O(1), O(n),
> >>O(nlogn)...)?  Are there
> >>other places where a bottleneck may exist aside
> > 
> > from
> > 
> >>gruffing with the
> >>policy?  Isn't the policy actually in xattrs so
> > 
> > it's
> > 
> >>O(1)?  Where else
> >>would an overhead that big come from aside from a
> >>lookup in a table?
> > 
> >>....
> > 
> >>Why is the sky blue?  Why do you have a mustach? 
> >>Why doesn't mommy have
> >>one?  Does she shave it?
> > 
> >>At any rate, my personal end goal is a secure
> >>high-performance operating
> >>system, as user friendly as Ubuntu, Mandriva, or
> >>Win----.  To this end,
> >>I'm (still; a lot of you have seen me before)
> >>evaluating the performance
> >>hit of various user and kernel security
> > 
> > enhancements
> > 
> >>like PaX,
> >>ProPolice, various OpenWall/GrSecurity niceness
> > 
> > that
> > 
> >>needs to be divided
> >>out, and of course LSM/SELinux.  Also wondering
> >>about that PHKMalloc
> >>thing on openbsd; is it really all that, is it
> > 
> > junk,
> > 
> >>how's it compare to
> >>the recent ptmalloc work, and can it run on Linux
> >>for direct benching .
> >>. . but that's off topic.
> > 
> >>--
> >>All content of all messages exchanged herein are
> >>left in the
> >>Public Domain, unless otherwise explicitly stated.
> > 
> >>    Creative brains are a valuable, limited
> >>resource. They shouldn't be
> >>    wasted on re-inventing the wheel when there
> > 
> > are
> > 
> >>so many fascinating
> >>    new problems waiting out there.
> > 
> > 
> > --
> > 
> >>Eric Steven Raymond
> > 
> > -
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
> >>__________________________________ 
> >>Yahoo! Mail - PC Magazine Editors' Choice 2005 
> >>http://mail.yahoo.com
> > 
> > 
> > --
> > All content of all messages exchanged herein are
> > left in the
> > Public Domain, unless otherwise explicitly stated.
> > 
> >     Creative brains are a valuable, limited
> > resource. They shouldn't be
> >     wasted on re-inventing the wheel when there
> are
> > so many fascinating
> >     new problems waiting out there.
> >                                                 
> --
> > Eric Steven Raymond
> - -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> > __________________________________ 
> > Yahoo! Mail - PC Magazine Editors' Choice 2005 
> > http://mail.yahoo.com
> 
> 
> - --
> All content of all messages exchanged herein are
> left in the
> Public Domain, unless otherwise explicitly stated.
> 
>     Creative brains are a valuable, limited
> resource. They shouldn't be
>     wasted on re-inventing the wheel when there are
> so many fascinating
>     new problems waiting out there.
>                                                  --
> Eric Steven Raymond
> -----BEGIN PGP SIGNATURE-----
> 
=== message truncated ===



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: The price of SELinux (CPU)

[Bill Davidsen]

Dan C Marinescu wrote:
> the benchmark "results" _look_ like being authored by
> some qa engineers... or sysadmins or something...
> 
> *** only a deep/intimate knowledge of kernel and fs
> and acl implementation details and many other areas
> could suggest a credible conclusion (most likely
> without even needing any "profiling" at all... on pure
> theoretical basis, mostly because you would know what
> goes where and when and how and why and how much it
> adds here and there, etc, etc, etc)

Any results not based on actual measurement are called "guesses" rather 
than "data." Such deep knowlege is useful to determine what to measure, 
not what you would measure if you thought it were necessary.

The measurements are very useful, in that they show the magnitude of the 
performance impact using a benchmark which was constructed to emulate 
certain real world loads. Since no one number or even series of numbers 
can fully describe what *will* happen, but these numbers show what 
*could* happen.
> 
> and i personally have a strong doubt that if the cpu
> activity was statistically increased with 7% for the
> very same elementary I/O, linus would have accepted
> this degradation... my $0.02... :-)

For some applications the issue isn't how fast the O/S runs, but if it 
is secure enough to be run at all. Given the speed of even commodity 
computers, it's probable that even a 2:1 slowdown would still result in 
useful operation, compared to doing the work without a computer.

I can't speak for Linus' thinking of course, but I have worked in secure 
environments before, both DOD and DOE, and information control is vital.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: The price of SELinux (CPU)

[Dan C Marinescu]

> Any results not based on actual measurement are
> called "guesses" rather 
> than "data." Such deep knowlege is useful to
> determine what to measure, 
> not what you would measure if you thought it were
> necessary.

in my world, we design stuff, calculate bigO, then
implement and finally measure. we don't write code at
inspiration and then measure and if kinda s*x we apply
patches then measure again, etc etc etc, that's _all_
i meant... (keep measuring something not really
designed for this O or that O may be a huge waste of
time). even in qa, the best engineers find
short-cuts... even in black box testing, but then you
get gray box, and white box testing and finally us
(r&d).

> The measurements are very useful, in that they show
> the magnitude of the 
> performance impact using a benchmark which was
> constructed to emulate 
> certain real world loads. Since no one number or
> even series of numbers 
> can fully describe what *will* happen, but these
> numbers show what 
> *could* happen.

correct, but you should measure something which you
first designed then implemented... not the other way
around...

> > very same elementary I/O, linus would have
> accepted
> > this degradation... my $0.02... :-)
> 
> For some applications the issue isn't how fast the
> O/S runs, but if it 
> is secure enough to be run at all. Given the speed

hey, absolutely... i was about to add that too (last
night) but it was kinda late... but how would you
define "secure"... it's kinda like huge, eh? in my
$0.02, secure means secure enough for the purpose
(whatever that may be...) and it's way over the scope
of this email... when this is equivalated with "oh,
it's kinda slow, but it's worth cause it's safer"...
well, i kinda have doubts on that... (check for a
second oppinion in your sec strategy, etc...)

> of even commodity 
> computers, it's probable that even a 2:1 slowdown
> would still result in 
> useful operation, compared to doing the work without
> a computer.

well, yes and now... it's a long story...

> I can't speak for Linus' thinking of course, but I
> have worked in secure 
> environments before, both DOD and DOE, and
> information control is vital.

yeah... remember the old days (running around with
floppies because networking was "unsafe" blah blah
blah...)

nice talking 2u bill,
   d

> 
> -- 
>     -bill davidsen (davidsen@tmr.com)
> "The secret to procrastination is to put things off
> until the
>   last possible moment - but no longer"  -me
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: The price of SELinux (CPU)

[Dan C Marinescu]

Hi John,

Don't buy that 7% increased CPU (can easily verify
it...)  start the kernel with selinux=0 (totally
disable selinux) and compare the results for
yourself...

Now about big_o... In two words, big O is a way of
describing the performance of an algorithm. If a
system has 2 deal with n steps it is said to be:
*constant O(1) if n doesn't affect the total run_time
of that system (eats the same amount of time
regardless n). O(n) is called linear (total
computation time is a linear dependency of n, that is
if it took 3 secs when n = 3, it would take 11 secs
when n = 11. And so on... (detail: in case of a
polinomial, only the highest power matters!) of
course, the lower the better! I have __big__ doubts
that NSA implemented something higher than linear...
(I suspect that their folks go from O(1) to O(ln(n))
// quality work... Anyway, if O(n) is somehow
acceptable for certain algorithms, O(n to power 2, 3,
n) are to be avoided at all cost! (see the widowz
“kernel” live example of quadratic micro-kernels ;-)

*** The perfect case is not (yet) defined in general
theory of computation. That would be O(0) when a
system performs an infinite number of elementary
computations in ZERO seconds :-) 
*** Same about O(infinite) // obviously the worst
case, when a (super lazy) system needs an eternity to
do... nothing! :-) // see frequent blue screens on
costco purchased personal computers :-)

The smartest the author, the lower the O! In user_land
O(n) is considered acceptable in most cases...

So, in two words, simply put, fast is good :-) && slow
is bad :-(


   Daniel


--- John Richard Moser <nigelenki@comcast.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've heard that SELinux has produced benchmarks such
> as 7% increased CPU
> load.  Is this true and current?  Is it dependent on
> policy?  What is
> the policy lookup complexity ( O(1), O(n),
> O(nlogn)...)?  Are there
> other places where a bottleneck may exist aside from
> gruffing with the
> policy?  Isn't the policy actually in xattrs so it's
> O(1)?  Where else
> would an overhead that big come from aside from a
> lookup in a table?
> 
> ....
> 
> Why is the sky blue?  Why do you have a mustach? 
> Why doesn't mommy have
> one?  Does she shave it?
> 
> At any rate, my personal end goal is a secure
> high-performance operating
> system, as user friendly as Ubuntu, Mandriva, or
> Win----.  To this end,
> I'm (still; a lot of you have seen me before)
> evaluating the performance
> hit of various user and kernel security enhancements
> like PaX,
> ProPolice, various OpenWall/GrSecurity niceness that
> needs to be divided
> out, and of course LSM/SELinux.  Also wondering
> about that PHKMalloc
> thing on openbsd; is it really all that, is it junk,
> how's it compare to
> the recent ptmalloc work, and can it run on Linux
> for direct benching .
> . . but that's off topic.
> 
> - --
> All content of all messages exchanged herein are
> left in the
> Public Domain, unless otherwise explicitly stated.
> 
>     Creative brains are a valuable, limited
> resource. They shouldn't be
>     wasted on re-inventing the wheel when there are
> so many fascinating
>     new problems waiting out there.
>                                                  --
> Eric Steven Raymond
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird -
> http://enigmail.mozdev.org
> 
>
iD8DBQFDQgT4hDd4aOud5P8RAoWBAJ0foEe4JcqDDlb7mMXQ6Z6FjCFjLACfdmJz
> +j2lCH7DpTlZK6zUztldEGI=
> =RzhA
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: The price of SELinux (CPU)

[James Morris]

On Tue, 4 Oct 2005, John Richard Moser wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've heard that SELinux has produced benchmarks such as 7% increased CPU
> load.

The overall performance hit across several micro and macro benchmarks, 
when last measured last year sometime, was around 7%, depending on 
workload and what you were testing.  It's a very rough figure and any 
serious benchmarking needs to be done for the intended workload.

The AVC is now linearly scalable (measured up to 32 processors) thanks to 
RCU and work by NEC.

>  Is this true and current?  Is it dependent on policy?  What is
> the policy lookup complexity ( O(1), O(n), O(nlogn)...)?  Are there
> other places where a bottleneck may exist aside from gruffing with the
> policy?  Isn't the policy actually in xattrs so it's O(1)?  Where else
> would an overhead that big come from aside from a lookup in a table?

The overhead is generally independent of policy size, as policy is cached 
in the AVC and most workloads use a trivial number of policy rules in a 
steady state (often less than 20).

So, generally, you'll only have a very small number of AVC entries active, 
although you could have some longish hash chains if policy has not been 
reloaded since boot.

Look in /selinux/avc for stats.

Googling for "selinux performance" will guide you to:
http://www.livejournal.com/users/james_morris/2153.html


- James
-- 
James Morris
<jmorris@namei.org>

Re: The price of SELinux (CPU)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

On Tue, 04 Oct 2005 00:28:40 EDT, John Richard Moser said:

> At any rate, my personal end goal is a secure high-performance operating
> system, as user friendly as 

Step 0: Sooner or later, "secure" and "user friendly" *will* come into conflict.
At that point, you have to make a choice. Note that in many cases, we *made* the
choice years or even decades ago, and we've gotten used to the choices made.
For instance, you'd certainly get better performance and user friendliness if
you just stubbed out permission() in fs/namei.c and capable(), and just had them
return "let the guy do it".  But somehow, I don't think anybody would find that
very palatable.

Similarly, the stuff that comes out of Redmond, in general, has security issues
precisely because they chose "user friendly" when they got to Step 0.  Being
able to put Javascript and/or executable binaries in e-mail for automatic
execution is certainly user-friendly - but it's not secure.

In any case, the overhead isn't 7%.  If anything, it's probably closer to 0.7%,
and dropping with each kernel release as the code gets tuned and optimized even
more.  And beware the impact of micro-optimizations and macro-performance - there
was recently a code change to reduce the number and size of avtab entries.  That
slowed down the actual code path slightly, but overall was actually a performance
win, especially on smaller memory-constrained machines, due to the drastic drop
in overall slab consumption.

And remember - the first time that a security system prevents (for example) an
exploit against an Apache bug from being used to take over a system, it's paid
for itself.  When the FBI faxes you that "Hold Evidence" order, it means you may
not be seeing that server again for weeks, if ever.....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: The price of SELinux (CPU)

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Valdis.Kletnieks@vt.edu wrote:
> On Tue, 04 Oct 2005 00:28:40 EDT, John Richard Moser said:
> 
> 
>>At any rate, my personal end goal is a secure high-performance operating
>>system, as user friendly as 
> 
> 
> Step 0: Sooner or later, "secure" and "user friendly" *will* come into conflict.

It's a lot later than you think.  A home desktop OS isn't a server OS;
and a server OS isn't a home desktop OS.  That being said, something
doesn't have to be as wide-open as the goatse guy's ass to be suitable
for every tom dick and moron.

> At that point, you have to make a choice. Note that in many cases, we *made* the
> choice years or even decades ago, and we've gotten used to the choices made.
> For instance, you'd certainly get better performance and user friendliness if
> you just stubbed out permission() in fs/namei.c and capable(), and just had them
> return "let the guy do it".  But somehow, I don't think anybody would find that
> very palatable.
> 

Would you now?  The performance gain would be negligible, even if it
were there; the user friendly factor would be pretty nil.  I mean the
user now can administrate his system without entering a password before
hitting the configuration center -- which he does every several weeks if
that.

Aside from this, viruses and spyware and worms can now run rampant and
do what they want to his system, and other users' idiotic actions on a
multi-user system affect him.  This is more user friendly?  No, I think
it's going in the opposite direction. . . .

The choice was made at Windows with "Let the desktop user run as
administrator;" in Linux it's typically made at "We've designed an OS
that runs very, very well with your account limited."  They're both
roughly equivalent in terms of user friendly (I think linux with Gnome
or KDE is actually easier, so does my mom).

> Similarly, the stuff that comes out of Redmond, in general, has security issues
> precisely because they chose "user friendly" when they got to Step 0.  Being
> able to put Javascript and/or executable binaries in e-mail for automatic
> execution is certainly user-friendly - but it's not secure.
> 

There's "user friendly," and then there's just ass.  Switzerland gives
each and every child a rifle and trains them to use it at age 12 IIRC;
this would be "user friendly."  Now, if you want to be just ass, hand
every 4 year old a gun with live ammunition and wait for them to put a
bullet in someone's brain and learn on their own that you shouldn't
shoot people unless you really mean it.

Open source programs achieve "user friendly" in a responsible manner.
Firefox doesn't have a local machine zone with javascript able to write
to files directly; thunderbird doesn't auto-run certain scripts; the
file browser isn't integrated into the web browser in anything but KDE
(which I personally dislike for other reasons).

> In any case, the overhead isn't 7%.  If anything, it's probably closer to 0.7%,
> and dropping with each kernel release as the code gets tuned and optimized even
> more.  And beware the impact of micro-optimizations and macro-performance - there
> was recently a code change to reduce the number and size of avtab entries.  That
> slowed down the actual code path slightly, but overall was actually a performance
> win, especially on smaller memory-constrained machines, due to the drastic drop
> in overall slab consumption.

Nice.  Some IBM guys said they're gonna rebench soon so I'm looking
forward to that, but this is reassuring.

> 
> And remember - the first time that a security system prevents (for example) an
> exploit against an Apache bug from being used to take over a system, it's paid
> for itself.  When the FBI faxes you that "Hold Evidence" order, it means you may
> not be seeing that server again for weeks, if ever.....

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDQsnwhDd4aOud5P8RAmmWAJ9JJquzIPzjVlm5w0OxrBAwOJP6gwCeOHYv
sVpFxYCDZvKbhUOq86dqog4=
=i9Fd
-----END PGP SIGNATURE-----

Re: The price of SELinux (CPU)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

On Tue, 04 Oct 2005 14:29:05 EDT, John Richard Moser said:

> Aside from this, viruses and spyware and worms can now run rampant and
> do what they want to his system, and other users' idiotic actions on a
> multi-user system affect him.  This is more user friendly?  No, I think
> it's going in the opposite direction. . . .

Virus writers are users too, you know.  :)

And the other users are users as well - what if the other user's "idiotic
action" is to nuke your 500Mbyte archive of alt.binaries.pictures.llama.sex
that's taking up the disk space that is keeping him from running the payroll
software?  In your world, rather than him being able to fix the problem, he has
to go find a sysadmin with the root password to fix it, causing delays and
being less friendly....

You seem to be intentionally trying to miss the basic point, which is that
any additional security ends up trading off against other things.

Non-execute stack is a Good Thing security-wise - but it breaks some code,
forcing upgrades and/or having to track down binaries and flag them as
"don't enforce NX stack".  And then those binaries are still vulnerable....

SELinux is, in general, also a Good Thing.  However, the fact that the policy
restricts what stuff can happen in the security context associated with
mail delivery (after all, you *don't* want arbitrary binaries running then, right?)
did some serious damage to the way I use procmail, which in some cases ended
up running other binaries.  OK, so my .procmailrc *is* a 600-line monster that
does a lot of odd stuff - the point was that I had to add even *more* contortions
to the way it works, which is even less user-friendly....



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: The price of SELinux (CPU)

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Valdis.Kletnieks@vt.edu wrote:
> On Tue, 04 Oct 2005 14:29:05 EDT, John Richard Moser said:
> 
> 
>>Aside from this, viruses and spyware and worms can now run rampant and
>>do what they want to his system, and other users' idiotic actions on a
>>multi-user system affect him.  This is more user friendly?  No, I think
>>it's going in the opposite direction. . . .
> 
> 
> Virus writers are users too, you know.  :)
> 
> And the other users are users as well - what if the other user's "idiotic
> action" is to nuke your 500Mbyte archive of alt.binaries.pictures.llama.sex
> that's taking up the disk space that is keeping him from running the payroll
> software?  In your world, rather than him being able to fix the problem, he has
> to go find a sysadmin with the root password to fix it, causing delays and
> being less friendly....
> 

Oh sure, except that. . .

1)  You shouldn't be screwing with the payroll system
2)  You're quota'd on any good setup
3)  You're fired

> You seem to be intentionally trying to miss the basic point, which is that
> any additional security ends up trading off against other things.
> 

It does, but put the degree to which it trades off in perspective.

Utilizing ProPolice, functions which contain a local character pointer
(char[]) are guarded.  These functions experience a minimal performance
hit; practically it can top-out at around 8% theoretical, although from
my perspective you could produce an empty function where the guard code
is 100% of its body.  The 8% theoretical is along the lines of:

void foo() {
  char a[6];
  strcpy(a, "hello");
}

Obviously strcpy()'s complexity decreases the overhead; this is some
strange hybrid of "theoretical maximum" with "practical maximum," which
comes out to be "theoretical practical maximum" which is nonsense, but
we'll just for the sake of discussion let that slide.

Anyway, a finite number of functions have such guard code; and the
overhead can be shown as a function y=1/x, where y is the overhead and x
is  the number of units of code run between entering and exiting the
function, assuming the code added by propolice is 1 unit.  In the end,
the overhead is pretty much nil for practical applications.

For your trade-off of some practical 0.1% increase in CPU load, your
applications do two things when a stack buffer is overflowed.  First,
they tell you what function produced the buffer that was overflowed, in
what source file; second, they immediately terminate (complain loudly).

This means that things that are fuzz may crash the program; but so will
attacks.  It also means that these crashes are easy to report in
valuable detail, and thus the bugs are fixed rather quickly.  In the
end, this produces cleaner, more stable code due to attention being
brought to bugs more directly.  Additionally, such bugs would cause
intermittent odd behavior ranging from things not working to program
freezes to data corruption; a sudden crash in place of these things is
hardly much of a trade-off.  Finally, deploying such a protection
doesn't suddenly unearth massive amounts of buggy code, because if there
were such bugs in force then there'd be massive amounts of odd behavior
already.

So you've traded nearly nothing in the practical sense for a great
enhancement in security in this example.  In some special applications,
a program with its own bug will trigger this, which may be a more major
trade-off; but you need access to the source code to add this protection
to anything anyway, so in this case it's just going to tell you how to
fix the bug anyway.

> Non-execute stack is a Good Thing security-wise - but it breaks some code,
> forcing upgrades and/or having to track down binaries and flag them as
> "don't enforce NX stack".  And then those binaries are still vulnerable....
> 

Right.  It breaks some (very little, typically) code.  Perspective please.

> SELinux is, in general, also a Good Thing.  However, the fact that the policy
> restricts what stuff can happen in the security context associated with
> mail delivery (after all, you *don't* want arbitrary binaries running then, right?)
> did some serious damage to the way I use procmail, which in some cases ended
> up running other binaries.  OK, so my .procmailrc *is* a 600-line monster that
> does a lot of odd stuff - the point was that I had to add even *more* contortions
> to the way it works, which is even less user-friendly....
> 

Special case that would have likely never arisen if you had such
restrictions when you started; or in the very least would have been
solved more elegantly.

> 

In the end, massive, intrusive security is not exactly the best thing
for security's sake; but anything you can get away with significantly
cleanly (i.e. you don't break 99% of the applications on 99% of home
users' desktops) is worth immediate focus for those who are so inclined.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDQuGhhDd4aOud5P8RAtbhAJ9p22xB3KhPQ9iywk7ug6VbAgKFlQCeN9Yp
si7fx6ngk4UU/H8KTNgeR0U=
=soXe
-----END PGP SIGNATURE-----

Re: The price of SELinux (CPU)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On Tue, 04 Oct 2005 16:10:10 EDT, John Richard Moser said:

> > And the other users are users as well - what if the other user's "idiotic
> > action" is to nuke your 500Mbyte archive of alt.binaries.pictures.llama.sex
> > that's taking up the disk space that is keeping him from running the payroll
> > software?  In your world, rather than him being able to fix the problem, he has
> > to go find a sysadmin with the root password to fix it, causing delays and
> > being less friendly....

> Oh sure, except that. . .
> 
> 1)  You shouldn't be screwing with the payroll system
> 2)  You're quota'd on any good setup

Ahem.  You're adding in more "user unfriendly" constraints again. :)
 
> In the end, massive, intrusive security is not exactly the best thing
> for security's sake; but anything you can get away with significantly
> cleanly (i.e. you don't break 99% of the applications on 99% of home
> users' desktops) is worth immediate focus for those who are so inclined.

Good.  Now hand me that crystal ball that lets us know for sure which of
those two categories any given security measure falls into.  How often do
we see "this shouldn't break anything" patches on this list that do, in fact,
manage to break something anyhow?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: The price of SELinux (CPU)

[Dan C Marinescu]

> Good.  Now hand me that crystal ball that lets us
> know for sure which of
> those two categories any given security measure
> falls into.  How often do
> we see "this shouldn't break anything" patches on
> this list that do, in fact,
> manage to break something anyhow?

it seams to me that the crystal ball is that there is
no crystal ball at all... and there shouldn't be...
:-) // @ least in sec...

   d 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: The price of SELinux (CPU)

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Valdis.Kletnieks@vt.edu wrote:
> On Tue, 04 Oct 2005 16:10:10 EDT, John Richard Moser said:
> 
> 
>>>And the other users are users as well - what if the other user's "idiotic
>>>action" is to nuke your 500Mbyte archive of alt.binaries.pictures.llama.sex
>>>that's taking up the disk space that is keeping him from running the payroll
>>>software?  In your world, rather than him being able to fix the problem, he has
>>>to go find a sysadmin with the root password to fix it, causing delays and
>>>being less friendly....
> 
> 
>>Oh sure, except that. . .
>>
>>1)  You shouldn't be screwing with the payroll system
>>2)  You're quota'd on any good setup
> 
> 
> Ahem.  You're adding in more "user unfriendly" constraints again. :)
>  
> 
>>In the end, massive, intrusive security is not exactly the best thing
>>for security's sake; but anything you can get away with significantly
>>cleanly (i.e. you don't break 99% of the applications on 99% of home
>>users' desktops) is worth immediate focus for those who are so inclined.
> 
> 
> Good.  Now hand me that crystal ball that lets us know for sure which of
> those two categories any given security measure falls into.  How often do
> we see "this shouldn't break anything" patches on this list that do, in fact,
> manage to break something anyhow?

I've seen PaX break Xine, Java, nVidia's retarded binary OpenGL, and
mplayer.  Aside from that everything else ran rather smooth on my
system, including X itself.  To fix this of course was a policy
adjustment that weakened the protections partially for each breaking
thing.  For a time I noticed native x86-64 Xine had a bug and would make
bad assumptions, and died on a vanilla linux kernel because an area
aside from stack/heap that defaulted to !PROT_EXEC was expected to be
executable; I actually needed PaX so I could equate PROT_READ to
PROT_EXEC for Xine.

When ASLR went into 2.6.13 there was talk about higher ASLR breaking
Oracle; and a little bit about Emacs breaking at times.  Wine also has
iffy issues with it that get addressed by an early hack, which is the
Wine devs being -quite- friendly.  Linus mentioned something about
mmap()ing a 2 gig email box into memory on IA-32.  Aside from that,
high-order ASLR shouldn't be a problem; and most of those issues vanish
on 64-bit systems anyway.

Exec Shield breaks a few things, about as much as PaX; but the compiler
was explicitly modified to turn Exec Shield off if the wind blows, so
they started with a relatively wide number of binaries with ES disabled
while RH tried to narrow it to essentials (a backwards approach if you
ask me).  You never see ES break stuff because of this.

Neither Spender nor me have seen the grsecurity/openwall "linking
restrictions" break anything, although I've heard one person report on
an obscure app not liking it for some strange reason.  Aside from that,
it's effective at keeping ahead of the game when it comes to /tmp file
races.

I don't think grsecurity's banning of any write access to /dev/*mem
except for the video memory area ever actually broke anything legitimate.

Position independent executables help ASLR such as from PaX or Exec
Shield be more effective; if the program isn't going to work with it,
it's flat out not going to compile.  If it compiles, it works.

ProPolice's protections only break programs with bugs.  To mis-fire
ProPolice, you have to actually write past the end of a stack based
buffer, ticking off the canary.  Of course, it immediately tells you
where the problem is so you can go fix your code.

I forsee PHKmalloc in OpenBSD, if it works as advertised, as doing the
same things ProPolice does, but to the heap.  This means slightly-buggy
apps will fall victim to sudden death.  Good riddance to bad rubbish;
may the developers correct all exposed bugs with expedience.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDQzQjhDd4aOud5P8RAtt7AJkBrPxss5dNMNrrSXQeQyZSDyr8OQCgjSVH
3aDc4HOcrLYRYLUGSxlPOFE=
=IZeX
-----END PGP SIGNATURE-----

Re: The price of SELinux (CPU)

[Bill Davidsen]

Valdis.Kletnieks@vt.edu wrote:
> On Tue, 04 Oct 2005 16:10:10 EDT, John Richard Moser said:

>>Oh sure, except that. . .
>>
>>1)  You shouldn't be screwing with the payroll system
>>2)  You're quota'd on any good setup
> 
> 
> Ahem.  You're adding in more "user unfriendly" constraints again. :)

I don't think promising a user that s/he can have N MB of disk is 
unfriendly at all.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: The price of SELinux (CPU)

[Bill Davidsen]

Valdis.Kletnieks@vt.edu wrote:
> On Tue, 04 Oct 2005 14:29:05 EDT, John Richard Moser said:
> 
> 
>>Aside from this, viruses and spyware and worms can now run rampant and
>>do what they want to his system, and other users' idiotic actions on a
>>multi-user system affect him.  This is more user friendly?  No, I think
>>it's going in the opposite direction. . . .
> 
> 
> Virus writers are users too, you know.  :)
> 
> And the other users are users as well - what if the other user's "idiotic
> action" is to nuke your 500Mbyte archive of alt.binaries.pictures.llama.sex
> that's taking up the disk space that is keeping him from running the payroll
> software?  In your world, rather than him being able to fix the problem, he has
> to go find a sysadmin with the root password to fix it, causing delays and
> being less friendly....
> 
> You seem to be intentionally trying to miss the basic point, which is that
> any additional security ends up trading off against other things.
> 
> Non-execute stack is a Good Thing security-wise - but it breaks some code,
> forcing upgrades and/or having to track down binaries and flag them as
> "don't enforce NX stack".  And then those binaries are still vulnerable....
> 
> SELinux is, in general, also a Good Thing.  However, the fact that the policy
> restricts what stuff can happen in the security context associated with
> mail delivery (after all, you *don't* want arbitrary binaries running then, right?)
> did some serious damage to the way I use procmail, which in some cases ended
> up running other binaries.  OK, so my .procmailrc *is* a 600-line monster that
> does a lot of odd stuff - the point was that I had to add even *more* contortions
> to the way it works, which is even less user-friendly....
> 
> 
Doesn't everyone have executables in their .procmailrc? Mine starts with 
a filter which may add one line to the mail header, quantifying exactly 
how badly it sucks. That's then used to take preemptive action against 
spam and other stuff I don't wnat or need to see.

That's a lot to give up.