Re: SElinux ?

On 2008-02-15, Nigel Wade <nmw@xxxxxxxxxxxx> wrote:

That shouldn't preclude the use of SELinux. SELinux *should* be useful in any
server environment, either multi-user or Internet servers. Just because there
are no spare servers for testing shouldn't rule it out.

Well, bear in mind that installing a product on a live server does run
the risk of causing problems, in this case it was with SELinux, no
need to damn the whole system because it trapped something it was
supposed to trap. Another time you install a package now that SELinux
is off it still might clobber something. You'll know what to check
next time, any fine-grained security system like that is going to need
careful treatment and learning. If you don't have the time to learn
it then if top-level security is important then it's vital to make the
time, but if you're in one of those environments where time is not
available to manage the servers to the level you'd like, then you'll
have to do what you have done, lower your sights. Alternatively, this
situation you've found yourself in is your first step into learning
how to admin SELinux in your environment.

There are other less complicated application-level trappers for linux
that are simpler to operate but provide potentially less security (all
of these systems provide as much security as the policy provides), I
can't remember the name of SELinux's main rival, just have a google
for "SELinux versus" and you'll find it, there used to be a fair bit
of mud-flinging amongst the various systems's advocates.

If I had the £50,000 it would cost to buy a hot spare then that's what I'd do.
Since I don't the only option is to install packages on a production server.

That to me is a middle-to-low security setup, security isn't important
enough to splash the extra cash, but you can still use SELinux. I'd
suggest when it comes to time to make some changes you bung it into
permissive mode, make the changes, check the SELinux logs and repair
any issues that crop up then go back to non-permissive mode. With
something like SELinux it's hard to know you've got all the possible
legitimate activities permitted in the policy, but that's the price
you pay for a fine-grained system like that. How is it suposed to
know that something is to be allowed if you don't tell it after all?
You have to find out what it's blocking and permit it if it's supposed
to happen, and often that's only possible with trial and error.

It's certainly not suitable for a standard user desktop install.

No, certainly not.

It *should* be for production servers, but in operation it is far
too delicate, and the consequences of failure too drastic, to be of
use in the situation where it should be most useful.

It's perfectly usable for a production server, as long as it's not one
of those fluid, changing every moment servers, which is hardly a good
environment for any security product worth its salt. What you seem to
be asking for is a system that can automatically decide what should
and shouldn't be happening, and that's just not going to happen and I
certainly wouldn't trust a system that re-wrote its policies on the fly!

As for packages providing their own SELinux policies, I wouldn't trust
those either. They are going to provide a policy that covers the
legitimate uses of the application, however that's not the same as a
policy that covers what you need the application to do. One of the
aims of a good SELinux security policy is to define what the
application *has* to do to perform the task in hand. In the case of
something like Apache, you don't want it to be allowed to do
everything that it can do, e.g. running all scripts in cgi-bin folder,
you want it to only be able to run specific scripts and to throw out
any requests for scripts that are not there. Only you can really tell
it what you want it to do. A provided policy plug-in would be a useful
guide but needs to be tweaked for your environment.

Your paranoia level isn't high enough to justify the use of SELinux
(you have after all turned it off), neither is mine 99% of the time in
fact I don't run it at all right now precisely because of the kind of
overhead that you've hit, but will do on a system I'll be putting
together soon-ish. That system will have a clearly defined set of
tasks to do, and won't be messed with unless really vital, and at
times when it's OK for it to be down. When a security vulnerability
crops up, I'll check it to see if it's actually exploitable, SELinux
when set up right can prevent most of them from being exploited so
they can be left until the next admin period before correcting. My
main use of it will be to ensure separation of users even in the event
of an application-level break-in, it's very good for that kind of
thing. I wouldn't want to run a server for exchanging sensitive files
without SELinux.

--
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/
.

Relevant Pages

  • RE: Windows Server 2003
    ... you're absolutely right in an enterprise environment. ... Subject: Windows Server 2003 ... seem security-related but I think it has everything do with security. ... Doesn't look like the most secure box in my network, ...
    (Security-Basics)
  • Re: Security in a hosted facility
    ... I work in that environment. ... We monitor access to the server, ... things that the customers might put on the server. ... The customer is responsible for the security of his ftp password, ...
    (Security-Basics)
  • Re: RPC over HTTP: Single server or FE/BE setup?
    ... Unless there is dire need for a FE server in your environment a single server scenario will do just fine. ... over HTTP setup for Oulook would tighten up security quite a bit since they ...
    (microsoft.public.exchange.admin)
  • Possible compromise of Windows Server 2003 security risk & unknown users
    ... I wanted to find out if anybody is aware of how a Windows Server 2003 ... onto the server and never allow them to have a desktop environment. ... If anybody could advise of this, or recommend any additional security checks ... or security logging software then this would be ideal. ...
    (microsoft.public.windows.server.general)
  • Possible compromise of Windows Server 2003 security risk & unknown users
    ... I wanted to find out if anybody is aware of how a Windows Server 2003 ... onto the server and never allow them to have a desktop environment. ... If anybody could advise of this, or recommend any additional security checks ... or security logging software then this would be ideal. ...
    (microsoft.public.windows.server.setup)