cliff at develix.com
Sat Apr 12 07:42:07 MSD 2008
On Sat, 2008-04-12 at 01:21 +0100, Ed W wrote:
> Cliff Wells wrote:
> > But that's pretty much the case no matter what you do. The security
> > frameworks simply prevent a broken/hacked application from being used to
> > further compromise the system. Using the example you gave earlier, to
> > prevent a hacked PHP application from opening a network connection. They
> > didn't prevent the PHP app from being hacked in the first place (nor
> > could they).
> Hmm, well I don't want to start a battle here, but I somewhat disagree.
> In my mind a vserver just gives you a completely normal server with no
> extra frills, but the point is that you can pare it down to the min
> software required
> The hardening stuff reduces the *capabilities* at the *process* level.
> So we can lock a particular process into only certain file systems and
> reduce the ability to execute all executables (ok, filepermissions do
> this also, but they are easy to misconfigure and hard to give proper
> granularity compared with a MAC specification). The ability to limit
> capabilities is very powerful though and can definitely be used to
> reduce the possibility of an app being hacked at all.
Yes and no. You can limit certain types of hacks, but for instance
there is no way you can prevent someone from tinkering with a WordPress
mysql instance to acquire user info or just defacing it.
This is my point about "scope". The security framework limits the scope
of potential attacks at the process level, but requires attention to
detail. The VPS limits the scope to the VPS level. While this isn't as
fine-grained as the security framework, it's sufficient to prevent the
entire system (I mean host system) from being compromised. Worst case
scenario is reinstalling the VPS which is typically quite easy.
> Some of the other hardening features can reduce the susceptability of
> applications to new exploits, eg stack overflows.
> An overlooked part of grsec (and perhaps others) is mandatory logging of
> events. For example segfaults are logged in syslog - this can be very
> useful for detecting a hack attempt. You can even log execution of
> certain binaries (filter out the known ones and you are left with an
> "interesting" list which may allow you to detect a breakin)
> > but in general the
> > purpose of security frameworks such as SELinux and GRSEC is to limit the
> > damage post-exploit.
> Well they certainly do that - but remember the ability to reduce
> *capabilities* also. You can pare an application back much more tightly
> than you can with only file permissions. The two frameworks you mention
> above allow you to really lock down a given binary very very tightly and
> so I think it's fair to say that they dramatically reduce the chance of
> an exploit as well as reducing the damage once one occurs?
Except that I'm unaware of any non-trivial application that is a single
application. Most web applications use at least a database, so that's
another layer susceptible to attack and a layer that exceptions must be
made for in the framework. As the complexity of web apps increase
(think WordPress) I think it will get more difficult to properly secure
them with a security framework without impeding the functionality of the
application. Of course, for any particular app, this may or may not be
true, but in general I think the trend is that way. Also, many apps
support user-installed plugins which further complicates the issue.
> A VPS in my mind really just gives you a much cleaner space to run each
> app in and hence reduces the severity of a breach (perhaps reduces the
> likely hood of a breach by having fewer services running, but that wasnt
> the biggest attraction to me)
Well, both, but limiting the scope of a potential attack to an easily
rebuilt VPS is the most appealing factor, IMHO. Limiting services might
help in general, but most attacks on websites happen at the web
application layer. The way I see it, if a system's primary purpose (VPS
or otherwise) is to provide a website, then if this service is
compromised then the attacker has won. Whether or not they also setup an
IRC bot isn't too relevant (and this is something I usually deal with at
the gateway level anyway [I happen to like pfsense]). The point is
they've compromised the primary purpose of the system, so protecting the
rest of the system becomes rather moot, except as secondary damage. I
don't think GRSEC (or any other security framework) is going to help
here, so the question becomes quick recovery (and hopefully an upgrade
of the application in question). This is where a VPS really helps.
Reinstalling a new OS on the bare metal can be time-consuming, whereas
rebuilding a VPS can take a relatively short time (especially if you
separate your services across VPS', so you don't need to rebuild things
like mail servers [ech!]).
> Anyway, both are useful to varying extents - I am certainly a big fan of
> vservers and grsec to a lesser extent
I'm inclined to think of virtualization as a primary defense and
security frameworks second, mostly for the recovery abilities I outlined
above, but also because the security frameworks require much more
thought and time to implement properly (and often you won't realize
mistakes until it's too late).
I should mention that I'm considering this from the standpoint of hosted
sites (which is what I do) rather than a specialized system (i.e.
intranet or dedicated server), so that affects my point of view.
More information about the nginx