Updated SELinux Release

Updated SELinux Release

[Stephen Smalley]

An updated SELinux release is available from the NSA SELinux web site;
see http://www.nsa.gov/selinux/news.cfm#R041102.  This release is based
on Linux 2.6.9, but the current SELinux patch for the kernel includes a
number of changes made after 2.6.9 was released, including the xattr
code consolidation, the send_sigurg mediation, the setscheduler deadlock
fix, the locking fixes for the sidtab and netif table, and the AVC
scalability work.  The checkpolicy policy compiler has been updated to
preserve port context ordering in order to allow sensible use of port
ranges, and this facility is now used by the example policy to map all
otherwise unspecified reserved ports to a distinct type that can be
tightly controlled.  Numerous improvements to libselinux,
policycoreutils, and policy have been merged.  An updated version of
setools from Tresys has been merged.  Updated userland patches and SRPMS
have been merged from the Fedora Core 3 development tree.

This release includes the first public release of a new tool by MITRE,
polgen, which attempts to generate policy for an application based on
patterns in its behavior.  polgen works by running a program under a
modified strace that supplements the normal trace output with security
context information, applying a set of filters to the enhanced trace
output, and running the filtered trace data through a pattern recognizer
that identifies common patterns and proposes suitable policy based on
these patterns.  A complete worked example is provided to help
illustrate the use of the tool, see the documentation available under
the doc subdirectory of the polgen source tree.  Please experiment with
this tool and provide feedback to help shape its future development.

I'd like to propose a couple of changes for future SELinux releases for
discussion:

1) I'd like to revive the proposal I originally made in 
http://marc.theaimsgroup.com/?l=selinux&m=107669747828428&w=2, i.e. drop
patched userland packages from the upstream SELinux releases and simply
refer people to the appropriate sites for the various distros (as is
already done in the selinux-doc README).  Maintenance of the SELinux
userland patches has been handled entirely by others for quite some
time, and I don't see any valid reason for us to continue carrying them
on the NSA site.  We only carry a small subset of the patched userland
packages on our site anyway (compared to the far more extensive set in
Fedora), and our site will always lag behind the latest versions
available for the various distros.  If a reference set is desired, it
could always be placed on the sourceforge site, although I think that a
review should be done of the complete set of patched packages in Fedora
to see whether any other packages should be included in the reference
set (and note that in some cases, SELinux modifications have been
directly integrated into the Fedora source tree and are not carried as
separate patches anymore).

2) I'd like to do away with the complete prepatched kernel tarball and
full userland tarball, and only distribute a kernel patch and the
individual component tarballs for checkpolicy, libsepol, libselinux,
policycoreutils, etc.  The prepatched kernel tarball doesn't seem very
useful to me, as most people likely want to combine the SELinux kernel
patch with other patches and prebuilt kernel packages with SELinux
support are available for the various distros now.  The full userland
tarball seems redundant to me, and packagers of SELinux are using the
individual component tarballs anyway.  Any objections to dropping these
two tarballs?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Karl MacMillan]

On Wed, 2004-11-03 at 10:39 -0500, Stephen Smalley wrote:
> I'd like to propose a couple of changes for future SELinux releases for
> discussion:
> 
> 1) I'd like to revive the proposal I originally made in 
> http://marc.theaimsgroup.com/?l=selinux&m=107669747828428&w=2, i.e. drop
> patched userland packages from the upstream SELinux releases and simply
> refer people to the appropriate sites for the various distros (as is
> already done in the selinux-doc README).  Maintenance of the SELinux
> userland patches has been handled entirely by others for quite some
> time, and I don't see any valid reason for us to continue carrying them
> on the NSA site.  We only carry a small subset of the patched userland
> packages on our site anyway (compared to the far more extensive set in
> Fedora), and our site will always lag behind the latest versions
> available for the various distros.  If a reference set is desired, it
> could always be placed on the sourceforge site, although I think that a
> review should be done of the complete set of patched packages in Fedora
> to see whether any other packages should be included in the reference
> set (and note that in some cases, SELinux modifications have been
> directly integrated into the Fedora source tree and are not carried as
> separate patches anymore).
> 

This certainly seems reasonable to me - I for one haven't used these for
almost a year.

> 2) I'd like to do away with the complete prepatched kernel tarball and
> full userland tarball, and only distribute a kernel patch and the
> individual component tarballs for checkpolicy, libsepol, libselinux,
> policycoreutils, etc.  The prepatched kernel tarball doesn't seem very
> useful to me, as most people likely want to combine the SELinux kernel
> patch with other patches and prebuilt kernel packages with SELinux
> support are available for the various distros now.  The full userland
> tarball seems redundant to me, and packagers of SELinux are using the
> individual component tarballs anyway.  Any objections to dropping these
> two tarballs?
> 

This also sounds appropriate to me.

I would also suggest that the external contributed tools be moved out of
the cvs repository. I think it is still nice to distribute tarballs of
the tools with the release, but the tools in cvs end up just being
snapshots (sometimes out of date). That would make the selinux sf cvs
repository just for core SELinux code, which seems like the right model.
The release process would become simply collecting tarballs from
contributors some days before the release and then placing them on the
webpage with the rest of the code on sf.

Karl

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Dhruv Gami]

On Wed, 3 Nov 2004, Stephen Smalley wrote:

> 2) I'd like to do away with the complete prepatched kernel tarball and
> full userland tarball, and only distribute a kernel patch and the
> individual component tarballs for checkpolicy, libsepol, libselinux,
> policycoreutils, etc.  The prepatched kernel tarball doesn't seem very
> useful to me, as most people likely want to combine the SELinux kernel
> patch with other patches and prebuilt kernel packages with SELinux
> support are available for the various distros now.  The full userland
> tarball seems redundant to me, and packagers of SELinux are using the
> individual component tarballs anyway.  Any objections to dropping these
> two tarballs?

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. 

I have met a number of people who have wanted to try out SELinux, or even 
Linux in general, but don't have either the expertise, or the time to 
learn how to get those tasks of patching and recompiling done. For a 
newbie, sometimes the sheer massiveness of the power available to him on a 
linux system is overwhelming enough. My point is that a number of newbies 
might get discouraged to even try out SELinux if they're unable to figure 
out how to download and patch their system. Most distributions don't 
install the kernel source code by default, and if its a newbie, im 
assuming he/she installed linux with the default options. He might not be 
aware of everything, but if he wants to try out something like SELinux 
that could make his system more secure, and if a single tarball is 
available to him, he can simply download that, compile it and be up and 
running with a SELinux system. 

I agree with Stephen that having the tarballs would be redundant as most 
of us prefer to get individual patches and patch our kernels, but I'm just 
thinking of the whole situation from a newbie's point of view. Old users 
sometimes don't realise it, but it can get intriguing for someone just 
starting out. Having something simple to use can be very helpful.

just my 2 cents.

regards,
Gami
-- 
Dhruv Gami
http://d10systems.com/gami


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Colin Walters]

On Wed, 2004-11-03 at 19:21 +0000, 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.  Linux distributions should be shipping with a SELinux-
enabled kernel and utilities by default.  Moreover, I think they should
be shipping it on by default in every install, with a targeted policy
like Fedora is doing, and a strict policy option.  We want SELinux to
get to the point where *not* having it on in some form is viewed a bit
like logging into your desktop as root.




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Manoj Srivastava]

On Wed, 03 Nov 2004 21:15:38 -0500, Colin Walters <walters@verbum.org> said: 

> On Wed, 2004-11-03 at 19:21 +0000, 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.

> Linux distributions should be shipping with a SELinux- enabled
> kernel and utilities by default.  Moreover, I think they should be
> shipping it on by default in every install, with a targeted policy
> like Fedora is doing, and a strict policy option.  We want SELinux
> to get to the point where *not* having it on in some form is viewed
> a bit like logging into your desktop as root.

	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.

	manoj
-- 
[It is] best to confuse only one issue at a time. K&R
Manoj Srivastava   <manoj.srivastava@stdc.com>    <srivasta@acm.org> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[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 <walters@verbum.org> said: 
> 
> > On Wed, 2004-11-03 at 19:21 +0000, 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.
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Colin Walters]

On Thu, 2004-11-04 at 13:15 +0000, 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 message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[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 +0000, 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.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Colin Walters]

On Fri, 2004-11-05 at 10:28 +0000, 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 +0000, 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.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Stephen Smalley]

On Fri, 2004-11-05 at 10:11, Colin Walters wrote:
> On Fri, 2004-11-05 at 10:28 +0000, 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 <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[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 +0000, 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 +0000, 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.
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Colin Walters]

On Fri, 2004-11-05 at 15:57 +0000, 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.




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Russell Coker]

On Saturday 06 November 2004 02:57, Luke Kenneth Casson Leighton 
<lkcl@lkcl.net> 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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Lorenzo Hernández García-Hierro]

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

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 
> <lkcl@lkcl.net> 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 <lorenzo@gnu.org> [1024D/6F2B2DEC]
[2048g/9AE91A22] Hardened Debian head developer & project manager

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Updated SELinux Release

[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 <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Stephen Smalley]

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 <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[James Morris]

On Thu, 4 Nov 2004, 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.

There is a performance hit and a scalability hit.  Some work by NEC on 
AVC scalability should be going into the upstream kernel soon.

The baseline performance hit seems to be around 7% (although it needs to
be evaluated again after the code is tuned), although on some networking
benchmarks it is as high as 20% for gigabit networking (no significant
performance hit is seen at 100Mbps).  Work is being done on both the
baseline and networking performance for intensive workloads.


- James
-- 
James Morris
<jmorris@redhat.com>



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Stephen Smalley]

On Thu, 2004-11-04 at 10:38, James Morris wrote:
> There is a performance hit and a scalability hit.  Some work by NEC on 
> AVC scalability should be going into the upstream kernel soon.
> 
> The baseline performance hit seems to be around 7% (although it needs to
> be evaluated again after the code is tuned), although on some networking
> benchmarks it is as high as 20% for gigabit networking (no significant
> performance hit is seen at 100Mbps).  Work is being done on both the
> baseline and networking performance for intensive workloads.

Right, but I think that the key issue as far as compile-time enabling of
SELinux is concerned is what performance hit is imposed by LSM itself,
because you can always disable SELinux at boot-time or runtime.  And you
can even trivially change the defaults for the boot-time parameter, as
SuSE did, so that selinux=0 is the default.  That allows users to still
enable SELinux without rebuilding the kernel, while only imposing the
overhead of LSM itself on non-SELinux users.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Stephen Smalley]

On Wed, 2004-11-03 at 14:21, Dhruv Gami wrote:
> He might not be 
> aware of everything, but if he wants to try out something like SELinux 
> that could make his system more secure, and if a single tarball is 
> available to him, he can simply download that, compile it and be up and 
> running with a SELinux system. 
> 
> I agree with Stephen that having the tarballs would be redundant as most 
> of us prefer to get individual patches and patch our kernels, but I'm just 
> thinking of the whole situation from a newbie's point of view. Old users 
> sometimes don't realise it, but it can get intriguing for someone just 
> starting out. Having something simple to use can be very helpful.

I would agree with this rationale (and indeed, it is why we originally
provided these tarballs) if it wasn't for the fact that any end user of
SELinux can now get both binary and source SELinux kernel and userland
packages for their distribution (at least Debian, Gentoo, Fedora, and
SuSE) from elsewhere (and in the cases of Fedora and Hardened Gentoo,
the SELinux code is already integrated into the distro for them), and
that will always be easier for end users than building from our source
tarballs.  At this point, I think that only people packaging SELinux for
the distros and reasonably skilled users will be directly using our
downloads, and I don't see any value in the complete tarballs to them.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Manoj Srivastava]

On Wed, 03 Nov 2004 10:39:40 -0500, Stephen Smalley <sds@epoch.ncsc.mil> said: 

> An updated SELinux release is available from the NSA SELinux web
> site; see http://www.nsa.gov/selinux/news.cfm#R041102.  

	I have been looking at the changes in libsepol, and I see
 these changes to the API:
======================================================================
-int mls_sid_to_context(context_struct_t * context,
+int mls_sid_to_context(policydb_t *policydb,
+                      context_struct_t * context,
                       char **scontext);

-int mls_context_to_sid(char oldc,
+int mls_context_to_sid(policydb_t *policydb,
+                      char oldc,
                       char **scontext,
                       context_struct_t * context);

-int mls_compute_sid(context_struct_t *scontext,
+int mls_compute_sid(policydb_t *policydb,
+                   context_struct_t *scontext,
                    context_struct_t *tcontext,
                    security_class_t tclass,
                    uint32_t specified,

-int sens_read(policydb_t * p, hashtab_t h, void * fp);
-int cat_read(policydb_t * p, hashtab_t h, void * fp);
+int sens_read(policydb_t * p, hashtab_t h, struct policy_file *fp);
+int cat_read(policydb_t * p, hashtab_t h, struct policy_file *fp);
======================================================================

	Unfortunately, this has not been accompanied with an soname
 change, this can't be a good thing.  I would suggest bumping up the
 soname to match the version (libsepol.so.1.2), to minimize confusion.

	manoj
-- 
The existence of god implies a violation of causality.
Manoj Srivastava   <manoj.srivastava@stdc.com>    <srivasta@acm.org> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Colin Walters]

On Wed, 2004-11-03 at 18:59 -0600, Manoj Srivastava wrote:
> On Wed, 03 Nov 2004 10:39:40 -0500, Stephen Smalley <sds@epoch.ncsc.mil> said: 
> 
> > An updated SELinux release is available from the NSA SELinux web
> > site; see http://www.nsa.gov/selinux/news.cfm#R041102.  
> 
> 	I have been looking at the changes in libsepol, and I see
>  these changes to the API:
> ======================================================================
> -int mls_sid_to_context(context_struct_t * context,
> +int mls_sid_to_context(policydb_t *policydb,
> +                      context_struct_t * context,

[...]

> 	Unfortunately, this has not been accompanied with an soname
>  change, this can't be a good thing.  I would suggest bumping up the
>  soname to match the version (libsepol.so.1.2), to minimize confusion.

I don't think anyone has actually been using these functions up until
now.  Neither Debian or Fedora enabled MLS, and I don't think Gentoo did
either.  So it's probably safe to continue using the existing soname;
but we should certainly be careful about this in the future.





--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Manoj Srivastava]

On Wed, 03 Nov 2004 22:37:42 -0500, Colin Walters <walters@verbum.org> said: 

>> Unfortunately, this has not been accompanied with an soname change,
>> this can't be a good thing.  I would suggest bumping up the soname
>> to match the version (libsepol.so.1.2), to minimize confusion.

> I don't think anyone has actually been using these functions up
> until now.  Neither Debian or Fedora enabled MLS, and I don't think
> Gentoo did either.  So it's probably safe to continue using the
> existing soname; but we should certainly be careful about this in
> the future.

	All right. Since Debian has not yet shipped a version of
 libsepol (it is still in incoming), I have noproblem with not bumping
 the soname.

	manoj
-- 
A good marriage would be between a blind wife and deaf husband. Michel
de Montaigne
Manoj Srivastava   <manoj.srivastava@stdc.com>    <srivasta@acm.org> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Stephen Smalley]

On Wed, 2004-11-03 at 22:37, Colin Walters wrote:
> I don't think anyone has actually been using these functions up until
> now.  Neither Debian or Fedora enabled MLS, and I don't think Gentoo did
> either.  So it's probably safe to continue using the existing soname;
> but we should certainly be careful about this in the future.

As a reminder, when I created libsepol from the checkpolicy core logic,
I had to export just about everything for use by checkpolicy via the
static library, but narrowly limited the API exported by the shared
library.  So we are free to rework the static library API at will, as
long as it doesn't affect the shared library API/ABI.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Christopher J. PeBenito]

On Thu, 2004-11-04 at 08:38 -0500, Stephen Smalley wrote:
> On Wed, 2004-11-03 at 22:37, Colin Walters wrote:
> > I don't think anyone has actually been using these functions up until
> > now.  Neither Debian or Fedora enabled MLS, and I don't think Gentoo did
> > either.  So it's probably safe to continue using the existing soname;
> > but we should certainly be careful about this in the future.
> 
> As a reminder, when I created libsepol from the checkpolicy core logic,
> I had to export just about everything for use by checkpolicy via the
> static library, but narrowly limited the API exported by the shared
> library.  So we are free to rework the static library API at will, as
> long as it doesn't affect the shared library API/ABI.

Well in this case, I believe these changes were because of the MLS
compile failures I had.  When the code was originally moved over to
libsepol from checkpolicy, the MLS functions weren't switched over from
the global policydb to the policydb pointer in the function call.  So
really, this fixes the broken API.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Stephen Smalley]

On Thu, 2004-11-04 at 13:25, Christopher J. PeBenito wrote:
> Well in this case, I believe these changes were because of the MLS
> compile failures I had.  When the code was originally moved over to
> libsepol from checkpolicy, the MLS functions weren't switched over from
> the global policydb to the policydb pointer in the function call.  So
> really, this fixes the broken API.

Right, the change corresponds with the patch I posted to the list in
response to those compilation failures for the optional MLS code
(disabled by default).  But they don't affect the shared library API/ABI
at all even with MLS enabled, because it doesn't export these
functions.  The shared library only exports the symbols marked global in
libsepol/src/libsepol.map.  Everything else is only exported by the
static library.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Updated SELinux Release

[Stephen Smalley]

On Wed, 2004-11-03 at 19:59, Manoj Srivastava wrote:
> 	I have been looking at the changes in libsepol, and I see
>  these changes to the API:
<snip>
> 	Unfortunately, this has not been accompanied with an soname
>  change, this can't be a good thing.  I would suggest bumping up the
>  soname to match the version (libsepol.so.1.2), to minimize confusion.

libsepol only exports a very limited API via the shared library.  The
majority of its API is only exported via the static library, and is only
for programs that are tightly coupled to it (like checkpolicy, from
which it was originally created).

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Updated SELinux Release

[Stephen Smalley]

An updated SELinux release is available from the NSA SELinux web site;
see http://www.nsa.gov/selinux/news.cfm#R050309. 

This release is based on Linux 2.6.11.  The SELinux kernel patch for
2.6.11 includes enhanced MLS support, changes to the execute-related
permission checking for legacy binaries, and an extension to the
/proc/pid/attr API to allow use by scripts.  Enhanced MLS support has
been merged into the userspace libraries and tools.  The libraries and
tools have been modified to allow local customization of file contexts
and users without requiring policy sources, and to preserve certain
types that are marked as being customizable upon relabels.  A helper
for running init scripts under a pty from run_init was merged.
setfiles was rewritten to use the matchpathcon library function.  The
technical reports in the selinux-doc package were updated to reflect
the current SELinux code.  The contributors page was updated.
Numerous patches for the userspace libraries, tools, and policy were
merged.  Updated versions of setools, slat, and polgen were added.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Updated SELinux Release

[Stephen Smalley]

An updated SELinux release is available from the NSA SELinux web site;
see http://www.nsa.gov/selinux/news.cfm#R050622.

This SELinux release is based on Linux 2.6.12.  The 2.6.12 kernel
includes the name_connect permission check for controlling outbound
connections.  The SELinux kernel patch for 2.6.12 includes the execstack
and execheap permission checks contributed by Lorenzo.  The hierarchical
role and type support by Tresys Technology has been merged into libsepol
and checkpolicy.  A new audit2why utility has been added to
policycoreutils to help identify the causes of avc denials. libsepol has
been re-licensed under the LGPL.  Updated versions of setools by Tresys
and polgen by MITRE were added.  A number of patches for the userspace
libraries, tools, and policy were merged.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Updated SELinux Release

[Stephen Smalley]

An updated SELinux release is available from the NSA SELinux web site;
see http://www.nsa.gov/selinux/news.cfm#R050907.

This SELinux release is based on Linux 2.6.13.  The 2.6.13 kernel
includes the execstack and execheap permission checks contributed by
Lorenzo and the support for default labeling of the MLS field by James
Morris.  The SELinux kernel patch for 2.6.13 includes support for atomic
security labeling of new inodes (for ext2, ext3, tmpfs only at present),
a generic VFS fallback for getting and setting security attributes on
filesystems that do not natively support EAs, and memory optimizations
for the policy's avtab.  Several of these changes have already been
upstreamed into Linus' git tree while others remain pending in the -mm
patchset.

In userspace, a number of enhancements to the libraries and utilities
have been merged.  These enhancements include the support for the new
binary policy version with the optimized avtab, a number of improvements
in abstraction and organization within libsepol by Ivan Gyurdiev, the
loadable policy module support by Tresys Technology (affecting libsepol,
checkpolicy, policycoreutils and adding libsemanage), and the context
translation support in libselinux based on work by Trusted Computer
Solutions and Red Hat.  Numerous bug fixes have also been merged, many
submitted by Serge Hallyn of IBM based on bugs discovered using the
Coverity tool.

With regard to the new binary policy version, checkpolicy -c 19 can be
used to generate the prior binary policy version for kernels that do not
yet have the necessary support.  As usual, both the SELinux module and
checkpolicy/libsepol provide backward compatibility for older binary
policy versions.

With regard to the policy module support, selinux-doc/README.MODULES has
some basic documentation of the module support, but further
documentation and man pages will be needed.  Note that libsemanage is
currently only available as a static library and limited to managing
policy modules (due to its origins as libsemod); it will be expanded in
the future to provide a more complete policy management API and to
provide a shared library with a stable API/ABI.

In this release, we have also stopped carrying copies of setools, slat,
and polgen on nsa.gov itself, but continue to provide links to the
respective Tresys Technology and MITRE SELinux sites where the latest
versions can always be obtained.  This avoids having stale copies around
on nsa.gov and ensures that people always acquire the latest version.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Updated SELinux Release

[Stephen Smalley]

An updated SELinux release is available from the NSA SELinux web site;
see http://www.nsa.gov/selinux/news.cfm#R050107.  This release is based
on Linux 2.6.10, but the current SELinux patch for the kernel includes a
number of changes merged after 2.6.10 was released, including the AVC
scalability work, AVC API and statistics support, dynamic context
transition support, and enhanced controls over executable mappings.  The
checkpolicy policy compiler has been updated to order node context
entries and to support supplementary type attribute declarations. 
Several improvements to libselinux, policycoreutils, and policy have
been merged.  Updated versions of setools, slat, and polgen were added. 
The selinux-doc CREDITS file
and Contributors web page have been updated.

As discussed on the list after the last release, we have reduced the NSA
SELinux release to just the core SELinux code, dropping the patched
userland packages, the prepatched kernel tarball, and the full userland
tarball.  Information about obtaining patched userland packages for
various distributions is available from the sourceforge selinux site
(http://selinux.sf.net), and a reference set of SELinux userland patches
is available in the public Fedora CVS tree.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Updated SELinux release

[Stephen Smalley]

An updated SELinux release is available from
http://www.nsa.gov/selinux/.  This release is based on Linux 2.6.8.1. 
The stable SELinux kernel now includes revalidation of the controlling
tty upon domain transitions.  The SELinux NFSv3 enhancements now include
revalidation of the inode security attributes from the server.  The core
checkpolicy logic has been moved into libsepol, a library for binary
policy manipulation.  Improved support for using policy booleans has
been integrated into load_policy and init, and many compile-time policy
tunables have been converted to runtime policy booleans.  Updated
userland patches and SRPMS have been merged from the Fedora Core 3
development tree.  A number of contributed patches have been merged for
the example policy and the policy core utilities. 

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.