[Fwd: Partial TOC for Comment]

[Fwd: Partial TOC for Comment]

[John Scroggins]

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



-------- Original Message --------
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
BCC: dataefx@earthlink.net
Message-ID: <3B7C61C3.29886E04@earthlink.net>
Date: Thu, 16 Aug 2001 17:13:55 -0700
From: John Scroggins <dataefx@earthlink.net>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.8-lsm i586)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Partial TOC for Comment
Content-Type:
multipart/mixed;boundary="------------F365DA8C7A05EE6BB97147FC"

Please give me your feedback/critique on the TOC, and if you can think
of additional subject headings (I do have more, but I want to see if
this is moving in the right directiom..)

TIA, 

John

[-- Attachment #2: adm082001.html --]
[-- Type: text/html, Size: 2659 bytes --]

[-- Attachment #3: adm082001-1.html --]
[-- Type: text/html, Size: 656 bytes --]

[-- Attachment #4: adm082001-2.html --]
[-- Type: text/html, Size: 941 bytes --]

[-- Attachment #5: adm082001-3.html --]
[-- Type: text/html, Size: 791 bytes --]

[-- Attachment #6: adm082001-4.html --]
[-- Type: text/html, Size: 682 bytes --]

Re: [Fwd: Partial TOC for Comment]

[Dale Amon]

On Thu, Aug 16, 2001 at 07:07:37PM -0700, John Scroggins wrote:
> Please give me your feedback/critique on the TOC, and if you can think
> of additional subject headings (I do have more, but I want to see if
> this is moving in the right directiom..)
> 

I'd suggest a spell checker :-)

Presumably the first sections will be a discussion of the why and
of the threat model and how SELinux secures you against those
classes of threats.

My personal feeling is that this sort of discussion throughout
will be important. I don't expect SELinux will protect against
all possible threats and it would be bad for someone new to
computer security to read a book, install it, and start
bragging. 

I'd say that a good section should be set aside to interpreting
log information. Having a "secure" system does you no good if
you just let the kiddies and the black hats tinker undisturbed.
Given peace and quiet and enough time, I'm sure *anyone* can
break into *anything*.

I find the idea of real time revokation interesting, because if
you see signs of an attack in progress, you can pull the rug
right out from under it... but again, only if you *realize* it
is an attack.

Some of these issues become much more complex in a public system
than in a closed system. In a closed and controlled environment
almost anything out of the ordinary is suspicious; and innocent
triggering is fairly easy to spot.

In summary, I think you need to tell not only how to set it up
and configure it and what the theory is behind it, but also
how to use it.




--
You have received this message because you are subscribed to the selinux 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: [Fwd: Partial TOC for Comment]

[Dale Amon]

On Fri, Aug 17, 2001 at 10:49:14AM -0700, John Scroggins wrote:
> > I find the idea of real time revokation interesting, because if
> > you see signs of an attack in progress, you can pull the rug
> > right out from under it... but again, only if you *realize* it
> > is an attack.
> > 
> After reading constantly for the last few days, help me out, please
> point me to the portion of text that speaks about R/T revocation, so I
> can build some info on that subject. 

I'm certainly not the best person here to discuss this: it is simply
something that I found of interest when I read the papers on the
technology. If you revoke a capability, the change will percoloate
through to even those who have already passed the gate and it will
stop them cold. (However I'm not sure now that I think of it whether
this feature was specific to FLASK or is part of SELinux).

I remember years back madly trying to finish up a project on
a computer account that was due to expire. I pulled an all-nighter
and the "revocation" of my account on that machine did not take
affect until *after* I logged out. While this was a nice feature
for a someone trying to finish a late project at a university,
it is not the best way to run a high security system ;-)

I think the designers like Dr. Smalley are much better sources
of information on this than I.

-- 
------------------------------------------------------
Use Linux: A computer        Dale Amon, CEO/MD
is a terrible thing          Village Networking Ltd
to waste.                    Belfast, Northern Ireland
------------------------------------------------------

--
You have received this message because you are subscribed to the selinux 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: [Fwd: Partial TOC for Comment]

[LeRoy Cressy]

Dale Amon wrote:
> 
> On Fri, Aug 17, 2001 at 10:49:14AM -0700, John Scroggins wrote:
> > > I find the idea of real time revokation interesting, because if
> > > you see signs of an attack in progress, you can pull the rug
> > > right out from under it... but again, only if you *realize* it
> > > is an attack.
> > >
> > After reading constantly for the last few days, help me out, please
> > point me to the portion of text that speaks about R/T revocation, so I
> > can build some info on that subject.
> 
> I'm certainly not the best person here to discuss this: it is simply
> something that I found of interest when I read the papers on the
> technology. If you revoke a capability, the change will percoloate
> through to even those who have already passed the gate and it will
> stop them cold. (However I'm not sure now that I think of it whether
> this feature was specific to FLASK or is part of SELinux).
There are some on this list using various forms of RPM or Debian package
management systems.  There is a package in the admin section of the
debian system called `slay' which will slay all the process of the user
mentioned.  If you see an unauthorized attack in progress happening you
can slay the user who is initiating the attack.  Slay will stop that
yser dead in their tracks.  As a system administrator you can then go
back and edit edit the /etc/passwd file and set the user's login shell
as false and place an * in the password field.  This will keep the
user's password in the shadow password file, but the user who's password
has been ``hacked'' can be reviewed to find the flaws in the user's
password.  


One way to tighten up security is to assign passwords and turn off the
SUID bit on /bin/passwd.  

> 
> I remember years back madly trying to finish up a project on
> a computer account that was due to expire. I pulled an all-nighter
> and the "revocation" of my account on that machine did not take
> affect until *after* I logged out. While this was a nice feature
> for a someone trying to finish a late project at a university,
> it is not the best way to run a high security system ;-)
> 
> I think the designers like Dr. Smalley are much better sources
> of information on this than I.
> 
> --
> ------------------------------------------------------
> Use Linux: A computer        Dale Amon, CEO/MD
> is a terrible thing          Village Networking Ltd
> to waste.                    Belfast, Northern Ireland
> ------------------------------------------------------
> 
> --
> You have received this message because you are subscribed to the selinux 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.

-- 
Rev. LeRoy D. Cressy   mailto:lcressy@telocity.com   /\_/\
                       http://www.netaxs.com/~ldc   ( o.o )
                       Phone:  215-535-4037          > ^ <

Jesus saith unto him, I am the way, the truth, and the life: 
no man cometh unto the Father, but by me. (John 14:6)

--
You have received this message because you are subscribed to the selinux 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: [Fwd: Partial TOC for Comment]

[Dale Amon]

On Sun, Aug 19, 2001 at 10:45:02AM -0400, LeRoy Cressy wrote:
> True, but doesn't selinux utilize all of the security measures built
> into Unix/Linux from years gone by?  Selinux is built on top of Linux
> with improvements and not replacemants.
> 

You must be missing the context of the discussion. We
are discussing the design issues of the SELinux and the
concepts of revocation via a security policy change at 
run time as discussed in the Flask papers on line, for 
use in Mr Scroggins book on SELinux. 

As I am no expert on SELinux, barely a neophyte
even, I've suggested that one of the designers discuss
this.

We're not discussing general unix security methods, as
that would be a bit off topic here.

-- 
------------------------------------------------------
Use Linux: A computer        Dale Amon, CEO/MD
is a terrible thing          Village Networking Ltd
to waste.                    Belfast, Northern Ireland
------------------------------------------------------

--
You have received this message because you are subscribed to the selinux 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: [Fwd: Partial TOC for Comment]

[Benjamin D. Thomas]

> In summary, I think you need to tell not only how to set it up
> and configure it and what the theory is behind it, but also
> how to use it.

Yes, agreed.  I like the format of the document and what you have is
great.  I just think it is missing sections on installation,
configuration, and common issues.  I realize that documents of this sort
have been written, but they should be compiled into this single document.

Thanks,

Ben


--
You have received this message because you are subscribed to the selinux 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: [Fwd: Partial TOC for Comment]

[John Scroggins]

"Benjamin D. Thomas" wrote:
> 
> > In summary, I think you need to tell not only how to set it up
> > and configure it and what the theory is behind it, but also
> > how to use it.
> 
> Yes, agreed.  I like the format of the document and what you have is
> great.  I just think it is missing sections on installation,
> configuration, and common issues.  I realize that documents of this sort
> have been written, but they should be compiled into this single document.
> 
> Thanks,
> 
> Ben

Thanks, all this input is great.. 

I was thinking along these lines -- due to the fact that SELinux already
has an INSTALL document, I was talking with a few people about scripting
a major portion of the commands, then possibly have some one work one a
UI similar to the kernel menuconfig dialog screen for editing the policy
files. I also believe this is the place to add the following items:

1) Getting the Kernel Source 
2) Editing the Policy Files (integrate the UI feature here) 
3) Building the Kernel (scripted to a single command like Debian
"makekpkg") and Related Tools
4) Relabeling the Filesystem (have a script which parses the contents of
the default file vs. current filesystem and edits or deletes the
appropriate entries) 

If we can get these to fly, then the amount of redundancy would be
limited.

--
You have received this message because you are subscribed to the selinux 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: [Fwd: Partial TOC for Comment]

[Conan Callen]

> I don't expect SELinux will protect against all possible threats ...
A chapter on SELinux scope would be helpful here. Listing additional
references, tools & techniques that
can be used along with SELinux to help find and plug the holes.

Also a scenarios section would be nice too. For instance "Building
Firewalls" has a whole chapter on different configurations. I want to set up
two configurations, a secured server running http & smtp, and a dual homed
firewall. The kinds of questions in my mind are "is there a better way that
I could be doing this?", "am I setting this up correctly?, did I miss
something ...?". For instance if it was just as secure to stick a second nic
into the server and make it the gateway as well, then I could spend more
effort on the one machine.

----- Original Message -----
From: "Dale Amon" <amon@vnl.com>
To: "John Scroggins" <dataefx@earthlink.net>
Cc: <SELinux@tycho.nsa.gov>
Sent: Thursday, August 16, 2001 4:12 PM
Subject: Re: [Fwd: Partial TOC for Comment]


>
> On Thu, Aug 16, 2001 at 07:07:37PM -0700, John Scroggins wrote:
> > Please give me your feedback/critique on the TOC, and if you can think
> > of additional subject headings (I do have more, but I want to see if
> > this is moving in the right directiom..)
> >
>
> I'd suggest a spell checker :-)
>
> Presumably the first sections will be a discussion of the why and
> of the threat model and how SELinux secures you against those
> classes of threats.
>
> My personal feeling is that this sort of discussion throughout
> will be important. I don't expect SELinux will protect against
> all possible threats and it would be bad for someone new to
> computer security to read a book, install it, and start
> bragging.
>
> I'd say that a good section should be set aside to interpreting
> log information. Having a "secure" system does you no good if
> you just let the kiddies and the black hats tinker undisturbed.
> Given peace and quiet and enough time, I'm sure *anyone* can
> break into *anything*.
>
> I find the idea of real time revokation interesting, because if
> you see signs of an attack in progress, you can pull the rug
> right out from under it... but again, only if you *realize* it
> is an attack.
>
> Some of these issues become much more complex in a public system
> than in a closed system. In a closed and controlled environment
> almost anything out of the ordinary is suspicious; and innocent
> triggering is fairly easy to spot.
>
> In summary, I think you need to tell not only how to set it up
> and configure it and what the theory is behind it, but also
> how to use it.
>
>
>
>
> --
> You have received this message because you are subscribed to the selinux
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.
>


--
You have received this message because you are subscribed to the selinux 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: [Fwd: Partial TOC for Comment]

[John Scroggins]

Conan Callen wrote:
> 
> > I don't expect SELinux will protect against all possible threats ...
> A chapter on SELinux scope would be helpful here. Listing additional
> references, tools & techniques that
> can be used along with SELinux to help find and plug the holes.
> 
> Also a scenarios section would be nice too. For instance "Building
> Firewalls" has a whole chapter on different configurations.

Good idea, but I think it out of scope for the preliminary document, but
I will install a placeholder for this element 

 I want to set up
> two configurations, a secured server running http & smtp, and a dual homed
> firewall. The kinds of questions in my mind are "is there a better way that
> I could be doing this?", "am I setting this up correctly?, did I miss
> something ...?". 

I can place references (URLs)to relevant material in the body of the doc
to take care of this situation..  

For instance if it was just as secure to stick a second nic
> into the server and make it the gateway as well, then I could spend more
> effort on the one machine.

Again, I want to move away from hardware, and distro issues of choice. 

Your input is great .. thanks 

--JS
> 

> >
> 
> --
> You have received this message because you are subscribed to the selinux 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.

--
You have received this message because you are subscribed to the selinux 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: [Fwd: Partial TOC for Comment]

[Dale Amon]

On Thu, Aug 16, 2001 at 07:07:37PM -0700, John Scroggins wrote:
> Please give me your feedback/critique on the TOC, and if you can think
> of additional subject headings (I do have more, but I want to see if
> this is moving in the right directiom..)

Incidentally, I note that your area seems to be SuSE Linux; I work
primarily with Debian releases and always roll my own moduleless
kernel. So any learning curve notes I supply will be from that 
viewpoint.


--
You have received this message because you are subscribed to the selinux 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: Partial TOC for Comment]

[Conan Callen]

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

SELinux Administrators GuideMore on supported scenarios -

As an example of the "Supported Scenario" idea is this:

The Redhat 7.1 Linux installer gives you the following choices:
Workstation
Server
Laptop
Custom System

It also allows you to choose your firewall settings.
Of coursed, depending upon what you select, the installer will place different components onto your system. A list of supported scenarios would also helps to limit the scope of customer support. When contacting redhat for support, I would imagine that the first thing they ask you is which sku you selected.

These represent what most people will be interested in over the next year or so. Supporting just this set would help to limit the scope of SELinux, and the amount of work that the dev's need to do. I dont know if there is an installer for SELinux (just finished the redhat install at last night) but if would be convienent if there was an install had a selection menu like the above list. Has anyone considered wraping selinux into an rpm package? 

Transactions on Software Engineering (Dec 1998, V24, N12) This is a special issue on the topic of using scenarios to determine requirements.

Conan

[-- Attachment #2: Type: text/html, Size: 2289 bytes --]

Re: Partial TOC for Comment]

[John Scroggins]

> Conan Callen wrote:
> 
> More on supported scenarios -
> 
> As an example of the "Supported Scenario" idea is this:

hmm.. sounds interesting.. good idea, I'll add that as a heading
9hopefully we will be able to fill it out ..;) 
> 
> The Redhat 7.1 Linux installer gives you the following choices:
> Workstation
> Server
> Laptop
> Custom System

I can leave a placeholder for laptops, but the primary focus will start
like this: servers --> workstations --> custom deployments 

> It also allows you to choose your firewall settings.
> Of coursed, depending upon what you select, the installer will place
> different components onto your system. A list of supported scenarios
> would also helps to limit the scope of customer support. When
> contacting redhat for support, I would imagine that the first thing
> they ask you is which sku you selected.

This sounds close to a distro specific guide, e.g. SELinux for RedHat
7.x Administrator Guide.. since the NSA has provided a source package, I
tend toward staying with a generic application. I would not want to box
some one into a distro descision.  


> These represent what most people will be interested in over the next
> year or so. Supporting just this set would help to limit the scope of
> SELinux,

agreed ..  

> and the amount of work that the dev's need to do. I dont know
> if there is an installer for SELinux (just finished the redhat install
> at last night) but if would be convienent if there was an install had
> a selection menu like the above list.

This is something I would like to do, but I am not skilled in this area
.. this is your chance to volunteer....  :)

 Has anyone considered wraping
> selinux into an rpm package?

Due to the fact SELinux is supposed to be secure, I will not support
.rpm installation documeentation in the guide. :( 
I am suggesting the package be built with installer which runs from a
shell (i.e., installSEL.sh)..I find no confidence in deploying a binary
type kernel package in a secure environ. Building from source is not an
option, at least in my mind.. I could be wrong .... let me know 

-- Cheers 

--JS  

> 
> Transactions on Software Engineering (Dec 1998, V24, N12) This is a
> special issue on the topic of using scenarios to determine
> requirements.
> 
> Conan

--
You have received this message because you are subscribed to the selinux 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: Partial TOC for Comment]

[Conan Callen]

.. this is your chance to volunteer....  :)

In the early 90's, I maintained a kornshell based installer for a unix
product (cim21 by Industrial Systems, bought up by AspenTech). That was a
while ago, but after I get my server up and running (and get SELinux
installed :) It had two parts, one would pull all the required files out of
the build tree and tar them up, and second part was the actual installer. I
rember much of how it was written, I think the key was the configuration
files. Once I get the fires under control I can play around with it.

On a different topic (installing linux and immediatly getting cracked):
An interesting note. As soon as I finished installing Linux lastnight, I
noticed the hard drive start whirling like someone was there doing searches
of my hard drive. This morning I got the same thing. I ran ps -aux and could
see a process as root running a something like ls | awk ... looking for
different things. I didnt take time to write it down, I just shut the
machine down.

It appears that as soon as I was done installing the system it was
compromised. It made me think that there must be hundreds / thousands of
people installing linux everyday and have the same thing happen and dont
even realize it. Its like the machine puts out a message to the internet as
soon as you turn it on "please, come hack me!"

Im in the process of locking the machine down now. I stared by pulling the
ethernet cable. Does SELinux help to make it tougher for the crackers to
gain access like this? Know of any good webpages / books on how to get
started (steps) on locking down a system, and creating scripts to monitor
the system?

Conan

----- Original Message -----
From: "John Scroggins" <dataefx@earthlink.net>
To: "Conan Callen" <ccallen@windowpane.com>
Cc: <SELinux@tycho.nsa.gov>; "Christopher Mahmood" <ckm@suse.com>
Sent: Friday, August 17, 2001 12:51 PM
Subject: Re: Partial TOC for Comment]


> > Conan Callen wrote:
> >
> > More on supported scenarios -
> >
> > As an example of the "Supported Scenario" idea is this:
>
> hmm.. sounds interesting.. good idea, I'll add that as a heading
> 9hopefully we will be able to fill it out ..;)
> >
> > The Redhat 7.1 Linux installer gives you the following choices:
> > Workstation
> > Server
> > Laptop
> > Custom System
>
> I can leave a placeholder for laptops, but the primary focus will start
> like this: servers --> workstations --> custom deployments
>
> > It also allows you to choose your firewall settings.
> > Of coursed, depending upon what you select, the installer will place
> > different components onto your system. A list of supported scenarios
> > would also helps to limit the scope of customer support. When
> > contacting redhat for support, I would imagine that the first thing
> > they ask you is which sku you selected.
>
> This sounds close to a distro specific guide, e.g. SELinux for RedHat
> 7.x Administrator Guide.. since the NSA has provided a source package, I
> tend toward staying with a generic application. I would not want to box
> some one into a distro descision.
>
>
> > These represent what most people will be interested in over the next
> > year or so. Supporting just this set would help to limit the scope of
> > SELinux,
>
> agreed ..
>
> > and the amount of work that the dev's need to do. I dont know
> > if there is an installer for SELinux (just finished the redhat install
> > at last night) but if would be convienent if there was an install had
> > a selection menu like the above list.
>
> This is something I would like to do, but I am not skilled in this area
> .. this is your chance to volunteer....  :)
>
>  Has anyone considered wraping
> > selinux into an rpm package?
>
> Due to the fact SELinux is supposed to be secure, I will not support
> .rpm installation documeentation in the guide. :(
> I am suggesting the package be built with installer which runs from a
> shell (i.e., installSEL.sh)..I find no confidence in deploying a binary
> type kernel package in a secure environ. Building from source is not an
> option, at least in my mind.. I could be wrong .... let me know
>
> -- Cheers
>
> --JS
>
> >
> > Transactions on Software Engineering (Dec 1998, V24, N12) This is a
> > special issue on the topic of using scenarios to determine
> > requirements.
> >
> > Conan
>


--
You have received this message because you are subscribed to the selinux 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: Partial TOC for Comment]

[Dale Amon]

On Fri, Aug 17, 2001 at 01:09:56PM -0700, Conan Callen wrote:

> On a different topic (installing linux and immediatly getting cracked):
> An interesting note. As soon as I finished installing Linux lastnight, I
> noticed the hard drive start whirling like someone was there doing searches
> of my hard drive. This morning I got the same thing. I ran ps -aux and could
> see a process as root running a something like ls | awk ... looking for
> different things. I didnt take time to write it down, I just shut the
> machine down.
> 

For the answer to your question, look at /etc/cron.*.

At various times of the wee hours, certain internal databases
are updated, in particular the locate db and the man db.

There are other cleanup tasks that occur as well.

I don't think you were hacked.

------------------------------------------------------
Use Linux: A computer        Dale Amon, CEO/MD
is a terrible thing          Village Networking Ltd
to waste.                    Belfast, Northern Ireland
------------------------------------------------------

--
You have received this message because you are subscribed to the selinux 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: Partial TOC for Comment]

[John Scroggins]

Conan Callen wrote:
> 
> .. this is your chance to volunteer....  :)
> 
> In the early 90's, I maintained a kornshell based installer for a unix
> product (cim21 by Industrial Systems, bought up by AspenTech). That was a
> while ago, but after I get my server up and running (and get SELinux
> installed :) It had two parts, one would pull all the required files out of
> the build tree and tar them up, and second part was the actual installer. I
> rember much of how it was written, I think the key was the configuration
> files. Once I get the fires under control I can play around with it.

Sounds like a plan ... when you are ready to start on something like
that we will need to talk to Chris M. also 
> 
> On a different topic (installing linux and immediatly getting cracked):
> An interesting note. As soon as I finished installing Linux lastnight, I
> noticed the hard drive start whirling like someone was there doing searches
> of my hard drive. This morning I got the same thing. I ran ps -aux and could
> see a process as root running a something like ls | awk ... looking for
> different things. I didnt take time to write it down, I just shut the
> machine down.

Next time let it run till you find the suspect process and identify its
function (you can minimize the affect by disconnecting the ethernet
cable instead of shutting down the machine..) 
> 
> It appears that as soon as I was done installing the system it was
> compromised. It made me think that there must be hundreds / thousands of
> people installing linux everyday and have the same thing happen and dont
> even realize it. Its like the machine puts out a message to the internet as
> soon as you turn it on "please, come hack me!"

Its unfortunate, but the 'net is being scanned constantly, most of the
time with automated tools. That is why it is essential to follow
specific protocols when setting up secure installations. I have had it
happen to me -- a few years ago ;) 
> 
> Im in the process of locking the machine down now. I stared by pulling the
> ethernet cable. Does SELinux help to make it tougher for the crackers to
> gain access like this? Know of any good webpages / books on how to get
> started (steps) on locking down a system, and creating scripts to monitor
> the system?

Without knowledge of "how" your box was _rooted_ , I will make a broad
brush statement: 

The flask architecture should significantly hinder processes that may be
exploited. Processes like httpd, ftpd, vixie-cron, and other other
vulnerable processes can be segregated into different domain/roles, and
if attacked and exploited, they will have to check with the kernel
subsystem (security server), which limits their system interaction based
on the policy configuration. 

You might want to check out http://www.rootprompt.org ,
http://www.sans.org and http://www.cert.org  (also try
www.ciac.llnl.gov)

Tip:

1) never install your system on the wire (hooked up), unless it is an
ftp/nfs install. 
2) after you install, run tripwire or some other file integrity checking
program. Or you can issue this command 
#/  touch chk.log 
#/ rpm -Va >  chk.log 
to let you know which packages were installed.

3) run 
#/ netstat -na |less 

and verify open ports 21-ftp 22-ssh 23-telnet 25-smtp 111 - 113-  

4) edit your /etc/inetd.conf (I think redhat uses a file called
/etc/services) file to limit services running and open ports.

5) install and configure  "portsentry"

6) install logcheck (or logwatch, whichever you prefer-)

7) setup a firewall (on a separate box) and run ipchains with Seattle
Firewall or pmFirewall or whatever you like 

8) plug it in and watch your logs ...  

Cheers.. 

--JS      
 
> Conan
>

--
You have received this message because you are subscribed to the selinux 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: Partial TOC for Comment]

[Westerman, Mark]

Conan Callen Wrote:
> Does SELinux help to make it tougher for the crackers to
>gain access like this? Know of any good webpages / books on how to get
>started (steps) on locking down a system, and creating scripts to
>monitor
>the system?

With a resound yes it does help. I had a Redhat box that used for
DNS. I was being lazy and did not update the box. Someone broke into
The DNS server and installed rootkit. I reloaded the server since I was
on his target list I got hit again (same as you.. Same day) I then reload
the box (offline) with selinux and created a named domain. Then the machine
was placed online. I did not update named to see if the named security
domain would work. Yes it works great. For the next week he kept tying, I
noticed in the logs where he was using buffer overflow to attacked the
named. He performed buffered overflow on the named server but was not able
to do any thing else to the system.

Mark Westerman
I very satisfied customer of SeLinux




--
You have received this message because you are subscribed to the selinux 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.