Re: Updated SELinux Release

2005-01-03 Thread Lorenzo Hernández García-Hierro
Hi Russell,

El lun, 03-01-2005 a las 23:53 +1100, Russell Coker escribió:
> On Saturday 06 November 2004 02:57, Luke Kenneth Casson Leighton 
> <[EMAIL PROTECTED]> wrote:
> >  debian doesn't GIVE users that choice [remember the adamantix
> >  bun-fight, anyone?] and instead settles for about the lowest possible
> >  common denominator - no consideration to modern security AT ALL!
> 
> Doing the things that Adamantix does takes some work.  The Adamantix people 
> are doing their own distribution and are not contributing to Debian.  There 
> are many Debian developers who want to see the same stuff included in Debian 
> (including me), but no-one with the right combination of interest, time, and 
> skills.
> 
> If someone is looking for things to work on then it would be a good place to 
> start.

I think that Hardened Debian is putting many efforts in terms of
security technologies deployment.
We are now working on the deployment in Ubuntu Linux as a first move
before the possible deployment in Debian.

I'm now interested in making SELinux a really reliable solution thus i
have the other things almost done, and some kernel work is already done.

The debian policies should be improved and creation of a work team would
be great.

I have a blank page at the wiki
(http://wiki.debian-hardened.org/SELinux_on_Debian) which could be a
start point.

As i'm new and even i don't know what's the current state of SELinux
Debian deployment, i would appreciate any information.

I've set up a site (BTW, running on a hardened debian powered "box")
where i'm maintaining patches and other stuff i worked on related with
SELinux, it's at http://selinux.tuxedo-es.org .

Cheers,
-- 
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC]
[2048g/9AE91A22] Hardened Debian head developer & project manager


signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada	digitalmente


Re: Updated SELinux Release

2005-01-03 Thread Russell Coker
On Saturday 06 November 2004 02:57, Luke Kenneth Casson Leighton 
<[EMAIL PROTECTED]> wrote:
>  debian doesn't GIVE users that choice [remember the adamantix
>  bun-fight, anyone?] and instead settles for about the lowest possible
>  common denominator - no consideration to modern security AT ALL!

Doing the things that Adamantix does takes some work.  The Adamantix people 
are doing their own distribution and are not contributing to Debian.  There 
are many Debian developers who want to see the same stuff included in Debian 
(including me), but no-one with the right combination of interest, time, and 
skills.

If someone is looking for things to work on then it would be a good place to 
start.

>  maybe it's just me with my weird setup [very likely], but
>  running mozilla under KDE 3.3.0 with selinux 2.6.8.1-selinux1
>  on a 256mb system P4 2.4Ghz) is a 10-11 second startup,
>  whereas if i set selinux=0 i've seen as fast as a THREE second
>  startup time.

That sounds bizarre.  What does "enforcing=0" give?  What if you kill klogd 
before starting it?

>  i've put KDE_IS_PRELINKED=1, KDE_FORK_SLAVES=1 into the
>  /usr/bin/startkde

/usr/bin/startkde in Debian sources *.sh from directories 
~/.kde/env, /usr/local/env, and /usr/env.  I think that
"kde-config --path exe" is not giving the most desirable results in this 
regard, and maybe we should have some other way of determining the path.

Something like /etc/kde/env would be a good directory for such things.  Then 
one of the SE Linux packages could drop a little script in that exports those 
variables.

Luke, could you please file appropriate bug reports about this

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page




Re: Updated SELinux Release

2004-11-05 Thread Colin Walters
On Fri, 2004-11-05 at 15:57 +, Luke Kenneth Casson Leighton wrote:

>  response 3: _is_ it the job of debian developers to dictate the minimum
>  acceptable security level?

It is absolutely Debian's job to provide a baseline level of security by
default.  Debian doesn't let you install a system by default without a
root password, or install a mail server that relays mail from any IP
address, etc.  You're encouraged to create a regular user account for
logins (IIRC).  Likewise, I think it should be part of the standard
Linux security practice to have SELinux enabled by default.  With the
targeted policy and all the flexibility it offers (e.g. just turn off
protection for Apache, keep protection for named/portmap/syslog etc on),
there's very little reason not to ship it on.






Re: Updated SELinux Release

2004-11-05 Thread Javier Fernández-Sanguino Peña
(...)
>  response 3: _is_ it the job of debian developers to dictate the minimum
>  acceptable security level?

yes, it is. But we have to weight in the needs of our users. We want, after 
all, our operating system to be used in a large set of environments and 
some of those might break when enabling SELinux (but we won't know until 
it's enabled so it's kind of a loophole)

>  basically what i mean is, in gentoo, it's a no-brainer: you set options
>  at the beginning of your build, come back [2 weeks? :) ] later and you
>  have a system with PAX stack smashing, lovely kernel, everything
>  hunky-dory.

In Debian is also a no-brainer, or, really, a similar no-brainer to Gentoo:

1.- Download your favorite kernel-source package
2.- Download the ExecShield/Adamatix(PaX+RSBAC)/SELinux kernel-packages
(or upstream patches)
3.- Build with make-kpkg and pointing it to the patches so that they get 
applied.
4.- Install the kernel and reboot

With sbuild/buildd etc you can actually recompile the whole distribution 
with whatever options you want to (including a patched gcc) either in your 
system or in a chroot. 

>  debian doesn't GIVE users that choice [remember the adamantix
>  bun-fight, anyone?] and instead settles for about the lowest possible
>  common denominator - no consideration to modern security AT ALL!

Debian does provide choices, the Adamantix stuff is packaged in Debian (it 
has seen few users, though). Debian does not yet provide packages compiled 
with SSP (which would be the other difference with Adamantix currently) but 
some people are working on in to find the best approach to that issue.

Maybe those choices are not sufficiently documented (or used) to be 
mainstream, but choices are there and they are as no-brainer as having a 
user compile the full Gentoo distribution.

Regards

Javier


signature.asc
Description: Digital signature


Re: Updated SELinux Release

2004-11-05 Thread Andres Salomon
On Fri, 05 Nov 2004 15:57:52 +, Luke Kenneth Casson Leighton wrote:
[...]
>  response 3: _is_ it the job of debian developers to dictate the minimum
>  acceptable security level?

It is the job of the kernel team to maintain the kernel.  That includes
ensuring the kernel runs correctly and quickly in the most common cases,
tailoring the kernel to the needs of our users, and allowing users to
simply drop in a kernel package and have it Just Work.  The same applies
to every other package in debian, really.  The minimum acceptable security
level falls under that, as well.  Most users are happy w/ the standard
unix permission system.  Demands for selinux are relatively new.


> 
>  basically what i mean is, in gentoo, it's a no-brainer: you set options
>  at the beginning of your build, come back [2 weeks? :) ] later and you
>  have a system with PAX stack smashing, lovely kernel, everything
>  hunky-dory.
> 
>  debian doesn't GIVE users that choice [remember the adamantix
>  bun-fight, anyone?] and instead settles for about the lowest possible
>  common denominator - no consideration to modern security AT ALL!
> 

Users always have the choice; that's what kernel-package is for.  Gentoo
requires you compile the kernel; you can do the same in debian to get
your pax/selinux/3rd party patches in your kernel.  Debian also provides
the option to simply download a kernel image, without having to bother
compiling anything.  The trade-off for doing that is that you won't get
your third party patches and unusual features.

I should probably mention that I find your claim about debian not taking
security into consideration quite insulting.  Don't expect people to bend
over backwards to accommodate your requests when you make such
inflammatory remarks.






Re: Updated SELinux Release

2004-11-05 Thread Marco d'Itri
On Nov 05, Stephen Smalley <[EMAIL PROTECTED]> wrote:

> Obviously, I'd prefer the default to be selinux=1, but as a temporary
> measure to getting SELinux compiled into the Debian kernel at all, I
> think it is reasonable to make the boot-time default selinux=0 in their
> kernel, as SuSE did with their kernel.  You can change the default via a
> config option, no patch required anymore.
Agreed. Anyway, I think that the really important part is having
userspace support, most of the SELinux early adopters are going to
compile their own kernels anyway.

-- 
ciao, |
Marco | [8983 inz3fxLlg0Dxk]


signature.asc
Description: Digital signature


Re: Updated SELinux Release

2004-11-05 Thread Stephen Smalley
On Fri, 2004-11-05 at 10:11, Colin Walters wrote:
> On Fri, 2004-11-05 at 10:28 +, Luke Kenneth Casson Leighton wrote:
> >  i would agree with stephen that it should be compiled in,
> >  default options "selinux=no".
> 
> I don't believe Stephen said that.  He said that the performance hit in
> that case is just the LSM hooks.

Obviously, I'd prefer the default to be selinux=1, but as a temporary
measure to getting SELinux compiled into the Debian kernel at all, I
think it is reasonable to make the boot-time default selinux=0 in their
kernel, as SuSE did with their kernel.  You can change the default via a
config option, no patch required anymore.

-- 
Stephen Smalley <[EMAIL PROTECTED]>
National Security Agency




Re: Updated SELinux Release

2004-11-05 Thread Luke Kenneth Casson Leighton
On Fri, Nov 05, 2004 at 10:11:01AM -0500, Colin Walters wrote:
> On Fri, 2004-11-05 at 10:28 +, Luke Kenneth Casson Leighton wrote:
> > On Thu, Nov 04, 2004 at 11:06:06PM -0500, Colin Walters wrote:
> > > On Thu, 2004-11-04 at 13:15 +, Luke Kenneth Casson Leighton wrote:
> > > 
> > > >  default: no.
> > > 
> > > Why not on by default, 
> > 
> >  i would agree with stephen that it should be compiled in,
> >  default options "selinux=no".
> 
> I don't believe Stephen said that.  He said that the performance hit in
> that case is just the LSM hooks.
 
 oh. yes.

> >  that gives people the choice, 
> 
> It doesn't make sense to make security a "choice".  The current Linux
> security model is simply inadequate.

 response 1: *shrug*.  that's their choice - and their problem.

 response 2: you don't have to tell _me_ that - i'm the mad one who is
 actively working on a debian/selinux distro!!! :)

 response 3: _is_ it the job of debian developers to dictate the minimum
 acceptable security level?

 basically what i mean is, in gentoo, it's a no-brainer: you set options
 at the beginning of your build, come back [2 weeks? :) ] later and you
 have a system with PAX stack smashing, lovely kernel, everything
 hunky-dory.

 debian doesn't GIVE users that choice [remember the adamantix
 bun-fight, anyone?] and instead settles for about the lowest possible
 common denominator - no consideration to modern security AT ALL!

> > without affecting performance.
> 
> That's just a bug, and it's being worked on.  

 cool.

> Personally I don't notice any performance problems.
 
 maybe it's just me with my weird setup [very likely], but
 running mozilla under KDE 3.3.0 with selinux 2.6.8.1-selinux1
 on a 256mb system P4 2.4Ghz) is a 10-11 second startup,
 whereas if i set selinux=0 i've seen as fast as a THREE second
 startup time.

 i've put KDE_IS_PRELINKED=1, KDE_FORK_SLAVES=1 into the
 /usr/bin/startkde and i've run prelink, but i have the nvidia drivers
 so the x-windows glx drivers are symlinks, which stops prelink from
 being able to do its job on them.

 also i recompiled kde 3.3.0 .debs with the latest gcc 3.3.

 so i'm not _entirely_ confident that my setup is a good example to
 follow (!)

-- 
--
you don't have to BE MAD   | this space| my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent| for an ego trip - and get kicked 
 you feel better!  I AM| can pay cash  | out for a even bigger one.
--




Re: Updated SELinux Release

2004-11-05 Thread Colin Walters
On Fri, 2004-11-05 at 10:28 +, Luke Kenneth Casson Leighton wrote:
> On Thu, Nov 04, 2004 at 11:06:06PM -0500, Colin Walters wrote:
> > On Thu, 2004-11-04 at 13:15 +, Luke Kenneth Casson Leighton wrote:
> > 
> > >  default: no.
> > 
> > Why not on by default, 
> 
>  i would agree with stephen that it should be compiled in,
>  default options "selinux=no".

I don't believe Stephen said that.  He said that the performance hit in
that case is just the LSM hooks.

>  that gives people the choice, 

It doesn't make sense to make security a "choice".  The current Linux
security model is simply inadequate.

http://www.nsa.gov/selinux/papers/inevit-abs.cfm

> without affecting performance.

That's just a bug, and it's being worked on.  Personally I don't notice
any performance problems.

> > with a targeted policy, for everyone?  
> 
>  debianites have yet to be convinced of the benefits of
>  _anything_ to do with selinux [irrespective of whether they
>  are actually _aware_ of its benefits]

That's what we're working on.





Re: Updated SELinux Release

2004-11-05 Thread Stephen Smalley
On Thu, 2004-11-04 at 23:06, Colin Walters wrote:
> Why don't we just run say EROS (http://www.eros-
> os.org/) instead?  A: Because what makes SELinux interesting is that it
> can run all of our legacy software.  By not shipping it on everywhere,
> we're not tapping that ability.

Some of us might argue that the EROS security model is inadequate...
See DTMach/DTOS/Flask papers and reports for discussion of why
capability-based models leave something to be desired.

-- 
Stephen Smalley <[EMAIL PROTECTED]>
National Security Agency




Re: Updated SELinux Release

2004-11-05 Thread Luke Kenneth Casson Leighton
On Thu, Nov 04, 2004 at 11:06:06PM -0500, Colin Walters wrote:
> On Thu, 2004-11-04 at 13:15 +, Luke Kenneth Casson Leighton wrote:
> 
> >  default: no.
> 
> Why not on by default, 

 i would agree with stephen that it should be compiled in,
 default options "selinux=no".

 that gives people the choice, without affecting performance.

> with a targeted policy, for everyone?  

 debianites have yet to be convinced of the benefits of
 _anything_ to do with selinux [irrespective of whether they
 are actually _aware_ of its benefits]

 i specifically recall seeing a message from 2002 "the more i learn
 about selinux, i like it less and less".

 that having been said, i believe, like i think you do, that a
 targetted policy for debian _would_ make selinux much easier
 to accept.

 l.




Re: Updated SELinux Release

2004-11-05 Thread Manoj Srivastava
On Fri, 05 Nov 2004 00:40:41 -0500, Andres Salomon <[EMAIL PROTECTED]> said: 

> Manoj, if you're referring to our conversation earlier on IRC, I
> said that I have no personal interest in selinux, but I had no
> problems with it being included as long as it's not a significant
> performance hit.  I requested that you take it up on the
> debian-kernel list, though.  That request still stands; the kernel
> team is not a single person, nor is it comprised an IRC channel.

I've had other conversations about this. And, incidentally, if
 SELinux is compiled, but not enabled, there is _no_ perceptible hit,
 significant or otherwise.

> I assume you're referring to #249510, in which Christoph mentioned
> it was a 5% performance penalty.  That's significant, especially for
> people who don't care about selinux.  Your argument of "well it's
> not 20%, is it?" is bogus; throwing features into the kernel, each
> having a 5% performance penalty hit, quickly add up.

Before this gets out of hand, the 5-7% performance hit is for
 SELinux being enabled; merely compiling it in, and having the
 default setting being that SELinux is disabled at boot time unless
 selinux=1 is given on the kernel command line means there is _no_
 performance hit of that magnitude.

All you have is LSM, at that point, and the number  quoted
 were for SELinux enabled kernels, not justr kernels with LSM.

Now, I am not proposing we enable SELinux with a tergeted
 policy (which would incur the 5-7% hit) -- I am merely asking the
 SELinux option be compiled in for Sarge.

manoj
-- 
GOOD-NIGHT, everybody ... Now I have to go administer FIRST-AID to my
pet LEISURE SUIT!!
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C




Re: Updated SELinux Release

2004-11-05 Thread Manoj Srivastava
On Thu, 04 Nov 2004 23:06:06 -0500, Colin Walters <[EMAIL PROTECTED]> said: 

> On Thu, 2004-11-04 at 13:15 +, Luke Kenneth Casson Leighton wrote:
>> default: no.

> Why not on by default, with a targeted policy, for everyone?
> SELinux's flexibility allows one to easily turn it off for specific
> services.  There's a lot of value in preventing a compromised or
> misconfigured syslogd or portmap daemon from destroying your system.
> Not to mention Apache; with the stronger version of can_network, the
> Slapper worm would have been stopped in its tracks (no outbound port
> 80 access).  Additionally, I'm working on securing some high-risk
> software using the targeted policy; something that would be
> difficult to impossible to do without SELinux.

> The entire point of SELinux is to bring strong, flexible mandatory
> access control to a mainstream operating system (Linux).  If it's
> not enabled by default, and limited to the few of us on this mailing
> list, what's the point?  Why don't we just run say EROS
> (http://www.eros- os.org/) instead?  A: Because what makes SELinux
> interesting is that it can run all of our legacy software.  By not
> shipping it on everywhere, we're not tapping that ability.

This is all very nice, but I think we need to take an
 evolutionary change to reach that goal. The first step, far more
 palatable than forcing SELinux (even with just a targeted policy) is
 to get SELinux in the default kernels, disabled by default at boot
 time.

manoj
-- 
Harp not on that string. William Shakespeare, "Henry VI"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C




Re: Updated SELinux Release

2004-11-04 Thread Andres Salomon
On Thu, 04 Nov 2004 13:15:44 +, Luke Kenneth Casson Leighton wrote:

> On Thu, Nov 04, 2004 at 01:02:35AM -0600, Manoj Srivastava wrote:
>> On Wed, 03 Nov 2004 21:15:38 -0500, Colin Walters <[EMAIL PROTECTED]> said: 
>> 
>> > On Wed, 2004-11-03 at 19:21 +, Dhruv Gami wrote:
>> >> Personally, i would prefer to have those two tarballs available. I
>> >> know most people using SELinux are familiar with patching the
>> >> kernel, and are generally familiar with how Linux works and know
>> >> their way around on a Linux system.
>> 
>> > But moving forward, we don't want people to have to patch their
>> > kernel or utilities.
>> 
>>  Moving waaay forward. I asked the Debian kernel team to
>>  consider  compiling in SELinux (perhaps disabled by default, for
>>  starters), and was told that that is not going to fly because of
>>  "significant performance hit" one takes by compiling SELinux in.  I
>>  did not have any data to refute the claim, so  that is where we sit.
>  

Manoj, if you're referring to our conversation earlier on IRC, I said that
I have no personal interest in selinux, but I had no problems with it
being included as long as it's not a significant performance hit.  I
requested that you take it up on the debian-kernel list, though.  That
request still stands; the kernel team is not a single person, nor is it
comprised an IRC channel. 


> i had a bun-fight with the people who have taken over from
herbert: at
>   the point where i told them that recompiling applications to be
>   optimised like yoper and gentoo distributions gives back performance
>   far in excess of that lost by selinux, i stopped hearing back from
>   them.
> 

I assume you're referring to #249510, in which Christoph mentioned it was
a 5% performance penalty.  That's significant, especially for people who
don't care about selinux.  Your argument of "well it's not 20%, is it?" is
bogus; throwing features into the kernel, each having a 5% performance
penalty hit, quickly add up.  

Furthermore, this isn't even going to be considered until post-sarge, so
there's little point arguing about it now.  Just like we've told the PAX
people (who, quite frankly, interest me more than the selinux people);
provide solid benchmarks showing exactly how little of a performance hit
the feature is, and we'll be more likely to include it.  Without hard
data, all you have are guesses (2%, 5%, hell, it could be 20% for all we
know.  List your sources).

And yes, different compilers may compile code that runs faster; that's
not news.  That does not mean we're going to slow other parts of the
system down to balance that out, if we obtain any speed benefits with
gcc-3.4.






Re: Updated SELinux Release

2004-11-04 Thread Colin Walters
On Thu, 2004-11-04 at 13:15 +, Luke Kenneth Casson Leighton wrote:

>  default: no.

Why not on by default, with a targeted policy, for everyone?  SELinux's
flexibility allows one to easily turn it off for specific services.
There's a lot of value in preventing a compromised or misconfigured
syslogd or portmap daemon from destroying your system.  Not to mention
Apache; with the stronger version of can_network, the Slapper worm would
have been stopped in its tracks (no outbound port 80 access).
Additionally, I'm working on securing some high-risk software using the
targeted policy; something that would be difficult to impossible to do
without SELinux.

The entire point of SELinux is to bring strong, flexible mandatory
access control to a mainstream operating system (Linux).  If it's not
enabled by default, and limited to the few of us on this mailing list,
what's the point?  Why don't we just run say EROS (http://www.eros-
os.org/) instead?  A: Because what makes SELinux interesting is that it
can run all of our legacy software.  By not shipping it on everywhere,
we're not tapping that ability.






[sds@epoch.ncsc.mil: Re: Updated SELinux Release]

2004-11-04 Thread Luke Kenneth Casson Leighton
- Forwarded message from Stephen Smalley <[EMAIL PROTECTED]> -

Envelope-to: [EMAIL PROTECTED]
Delivery-date: Thu, 04 Nov 2004 16:37:30 +
X-Sieve: CMU Sieve 2.2
Subject: Re: Updated SELinux Release
From: Stephen Smalley <[EMAIL PROTECTED]>
To: Manoj Srivastava <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Organization: National Security Agency
X-Mailing-List: selinux-tycho.nsa.gov
X-hands-com-MailScanner: Found to be clean
X-MailScanner-From: [EMAIL PROTECTED]

On Thu, 2004-11-04 at 02:02, Manoj Srivastava wrote:
>   Moving waaay forward. I asked the Debian kernel team to
>  consider  compiling in SELinux (perhaps disabled by default, for
>  starters), and was told that that is not going to fly because of
>  "significant performance hit" one takes by compiling SELinux in.  I
>  did not have any data to refute the claim, so  that is where we sit.

Given that SELinux supports disabling both at boot time (via selinux=0)
and at runtime (via /selinux/disable, only useable prior to the initial
policy load, used by the patched /sbin/init when /etc/selinux/config
specifies disabled), the only performance impact they can truly claim is
fundamental to enabling SELinux at compile-time is the overhead of LSM
itself.  So ask for measurements showing that LSM in 2.6 imposes a
significant overhead by itself, and don't accept measurements based on
old versions of LSM prior to 2.6.

>   While a laudable long term goal, the reality is that most
>  distributions do not ship these utilities today, and in the case of
>  Debian, progress, while it is happening, is slow enough that
>  pragmatism requires we consider the reality that SELinux shall _not_
>  be the default in the near term.

Fedora (and RHEL4) and Hardened Gentoo have extensive SELinux
integration, and SuSE 9.x had the SELinux code included in the kernel
and a subset of the userland, just disabled by default.

-- 
Stephen Smalley <[EMAIL PROTECTED]>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [EMAIL PROTECTED] with
the words "unsubscribe selinux" without quotes as the message.

- End forwarded message -

-- 
--
you don't have to BE MAD   | this space| my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent| for an ego trip - and get kicked 
 you feel better!  I AM| can pay cash  | out for a even bigger one.
--




Re: Updated SELinux Release

2004-11-04 Thread Luke Kenneth Casson Leighton
On Thu, Nov 04, 2004 at 01:02:35AM -0600, Manoj Srivastava wrote:
> On Wed, 03 Nov 2004 21:15:38 -0500, Colin Walters <[EMAIL PROTECTED]> said: 
> 
> > On Wed, 2004-11-03 at 19:21 +, Dhruv Gami wrote:
> >> Personally, i would prefer to have those two tarballs available. I
> >> know most people using SELinux are familiar with patching the
> >> kernel, and are generally familiar with how Linux works and know
> >> their way around on a Linux system.
> 
> > But moving forward, we don't want people to have to patch their
> > kernel or utilities.
> 
>   Moving waaay forward. I asked the Debian kernel team to
>  consider  compiling in SELinux (perhaps disabled by default, for
>  starters), and was told that that is not going to fly because of
>  "significant performance hit" one takes by compiling SELinux in.  I
>  did not have any data to refute the claim, so  that is where we sit.
 
  i had a bun-fight with the people who have taken over from herbert:
  at the point where i told them that recompiling applications to be
  optimised like yoper and gentoo distributions gives back performance
  far in excess of that lost by selinux, i stopped hearing back from
  them.

>   While a laudable long term goal, the reality is that most
>  distributions do not ship these utilities today, and in the case of
>  Debian, progress, while it is happening, is slow enough that
>  pragmatism requires we consider the reality that SELinux shall _not_
>  be the default in the near term.
 
 default: no.

 available as an additional package: why not?

 heck, personally i wouldn't even care if it was i386 or 686 only.

 l.

-- 
--
you don't have to BE MAD   | this space| my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent| for an ego trip - and get kicked 
 you feel better!  I AM| can pay cash  | out for a even bigger one.
--