public inbox for gentoo-hardened@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-hardened] Remove toolchain?
@ 2010-02-01 12:35 Hinnerk van Bruinehsen
  2010-02-01 13:33 ` Ed W
  2010-02-01 14:35 ` schism
  0 siblings, 2 replies; 6+ messages in thread
From: Hinnerk van Bruinehsen @ 2010-02-01 12:35 UTC (permalink / raw
  To: gentoo-hardened

Hello everyone,

I'm trusted with building a hardened server. I'm using Gentoo on my
desktops for years, so hardened Gentoo is an obvious choice for me.

But there is one thing which disturbs me: Since Gentoo (and hardened
Gentoo) is sourcebased, i'll need a complete toolchain to keep the
system up to date.

I don't like the idea of giving this tools to someone who might
compromise the server.

Is there a way to keep the toolchain on a thumbdrive or in an encrypted
partition, so that a possible attacker can't use it, while I have still
access to it? Does a how-to or a guide exist, which coud guide me
through the process of setting it up correctly?

A quick google-search turned up nothing, though it may be possible, that
I'm just using the wrong keywords.

Any help would be greatly appreciated!

Kind regards,

Hinnerk




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-hardened] Remove toolchain?
  2010-02-01 12:35 [gentoo-hardened] Remove toolchain? Hinnerk van Bruinehsen
@ 2010-02-01 13:33 ` Ed W
  2010-02-01 14:35 ` schism
  1 sibling, 0 replies; 6+ messages in thread
From: Ed W @ 2010-02-01 13:33 UTC (permalink / raw
  To: gentoo-hardened

On 01/02/2010 12:35, Hinnerk van Bruinehsen wrote:
> s one thing which disturbs me: Since Gentoo (and hardened
> Gentoo) is sourcebased, i'll need a complete toolchain to keep the
> system up to date.
>
> I don't like the idea of giving this tools to someone who might
> compromise the server.
>
> Is there a way to keep the toolchain on a thumbdrive or in an encrypted
> partition, so that a possible attacker can't use it, while I have still
> access to it? Does a how-to or a guide exist, which coud guide me
> through the process of setting it up correctly

You have a 90% working solution through compiling and distributing 
binary packages.  The constraints are that you need to sync your USE 
flags and compile flags, or use multiple binary repositories.

I actually use something partially similar to keep a bunch of 
linux-vservers in sync - I maintain a set of custom profiles which 
inherit from the hardened profile and these are customised for each 
server "type", eg I have a hardened-apache and a hardened-nginx and a 
hardened-postfix, etc profile. I use linux-vservers so that I can have 
very fine grained app installations and flexibility to swap hardware (eg 
nearly all web applications get their own complete virtual machine...).  
Largely the USE flags/compile flags are all set in my profiles, but I do 
relax this a little bit as I allow toolchain on each vserver (which you 
are avoiding, so vary your setup)

There are some limitations with binary packages in that new users don't 
seem to get created correctly (see various history on the -embedded 
list).  This can be worked around in general, but just beware of that 
small issue

One feature that I like but don't exploit about linux-vservers is that 
in theory you can easily use the host tools to test/verify the guest 
installation - this means double trouble if the host is compromised, but 
potentially allows interesting avenues to detect compromised guests by 
examining them from the host.  Probably similar things can be done with 
all other virtualisation solutions also.

Quick checklist is that whatever solution you pick it should DEFINITELY 
include virtualised guest right from the word go...

I have found gentoo a very good fit for maintaining a long term 
installation without the pain of re-installs which you eventually 
encounter with Redhat/debian solutions.  However, I would suggest that 
the base level of experience required to manage the server is higher, 
but the payoff is much greater control and ease of management.  Over to 
you to decide if these tradeoffs are manageable, but big thumbs up from 
me for our needs.

Good luck

Ed W



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-hardened] Remove toolchain?
  2010-02-01 12:35 [gentoo-hardened] Remove toolchain? Hinnerk van Bruinehsen
  2010-02-01 13:33 ` Ed W
@ 2010-02-01 14:35 ` schism
  2010-02-01 15:07   ` Shinkan
  2010-02-02 11:34   ` basile
  1 sibling, 2 replies; 6+ messages in thread
From: schism @ 2010-02-01 14:35 UTC (permalink / raw
  To: gentoo-hardened

On Mon, Feb 01, 2010 at 01:35:10PM +0100, Hinnerk van Bruinehsen wrote:
> But there is one thing which disturbs me: Since Gentoo (and hardened
> Gentoo) is sourcebased, i'll need a complete toolchain to keep the
> system up to date.
> 
> I don't like the idea of giving this tools to someone who might
> compromise the server.

Removing the toolchain is an old, common misconception whose originator
I would love to meet and slap some sense into.

What exactly are you defending against?  If the server is compromised,
it's game over - they'll run whatever code they want, be that [highly
unlikely] compiling a binary to attack further or [highly likely] use a
pre-compiled static binary of their own.  If you don't have a toolchain
and they must have one, they'll download a static one and bootstrap it.

Better to learn the use of a good access control system like the
grsecurity RBAC that is integrated into hardened-gentoo to prevent
misuse of the toolchain than to go through fragile and unsupportable
gyrations trying to prevent a phantom threat.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-hardened] Remove toolchain?
  2010-02-01 14:35 ` schism
@ 2010-02-01 15:07   ` Shinkan
  2010-02-02 11:34   ` basile
  1 sibling, 0 replies; 6+ messages in thread
From: Shinkan @ 2010-02-01 15:07 UTC (permalink / raw
  To: gentoo-hardened

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

2010/2/1 <schism@subverted.org>

>
> Removing the toolchain is an old, common misconception whose originator
> I would love to meet and slap some sense into.
>
> What exactly are you defending against?  If the server is compromised,
> it's game over - they'll run whatever code they want, be that [highly
> unlikely] compiling a binary to attack further or [highly likely] use a
> pre-compiled static binary of their own.  If you don't have a toolchain
> and they must have one, they'll download a static one and bootstrap it.
>
> Better to learn the use of a good access control system like the
> grsecurity RBAC that is integrated into hardened-gentoo to prevent
> misuse of the toolchain than to go through fragile and unsupportable
> gyrations trying to prevent a phantom threat.
>
>
I would agree on that.
But sometimes you have to answer some needs which are expressed by a
hierarchy level you can't slap some sense into.
Unless you want to start writing a new résumé.

If you have choice, then let base Gentoo tools and just control access.

-- 
Pierre.
"Sometimes when I'm talking, my words can't keep up with my thoughts. I
wonder why we think faster than we speak. Probably so we can think twice." -
Bill Watterson

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-hardened] Remove toolchain?
  2010-02-01 14:35 ` schism
  2010-02-01 15:07   ` Shinkan
@ 2010-02-02 11:34   ` basile
  2010-02-02 13:37     ` Ed W
  1 sibling, 1 reply; 6+ messages in thread
From: basile @ 2010-02-02 11:34 UTC (permalink / raw
  To: gentoo-hardened

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

schism@subverted.org wrote:
> On Mon, Feb 01, 2010 at 01:35:10PM +0100, Hinnerk van Bruinehsen wrote:
>   
>> But there is one thing which disturbs me: Since Gentoo (and hardened
>> Gentoo) is sourcebased, i'll need a complete toolchain to keep the
>> system up to date.
>>
>> I don't like the idea of giving this tools to someone who might
>> compromise the server.
>>     
>
> Removing the toolchain is an old, common misconception whose originator
> I would love to meet and slap some sense into.
>   
In fact, this itself is the answer to what to do if you want to remove
the toolchain.  If you have several similar machines, you could use one
to compile and build the .tbz2 packages for updates to deploy to those
machines that do not have a toolchain.

Having said that, I agree that removing the toolchain is weak defense
and you should use rbac.

-- 

Anthony G. Basile, Ph.D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
USA

(716) 829-8197




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-hardened] Remove toolchain?
  2010-02-02 11:34   ` basile
@ 2010-02-02 13:37     ` Ed W
  0 siblings, 0 replies; 6+ messages in thread
From: Ed W @ 2010-02-02 13:37 UTC (permalink / raw
  To: gentoo-hardened

On 02/02/2010 11:34, basile wrote:
> schism@subverted.org wrote:
>    
>> On Mon, Feb 01, 2010 at 01:35:10PM +0100, Hinnerk van Bruinehsen wrote:
>>
>>      
>>> But there is one thing which disturbs me: Since Gentoo (and hardened
>>> Gentoo) is sourcebased, i'll need a complete toolchain to keep the
>>> system up to date.
>>>
>>> I don't like the idea of giving this tools to someone who might
>>> compromise the server.
>>>
>>>        
>> Removing the toolchain is an old, common misconception whose originator
>> I would love to meet and slap some sense into.
>>
>>      
> In fact, this itself is the answer to what to do if you want to remove
> the toolchain.  If you have several similar machines, you could use one
> to compile and build the .tbz2 packages for updates to deploy to those
> machines that do not have a toolchain.
>
> Having said that, I agree that removing the toolchain is weak defense
> and you should use rbac.
>
>    

I personally like the hardened project, but I think it's easy to 
overlook that usually the biggest weaknesses (and most probed areas of 
exploit right now) are something like:

- Bad passwords for ssh/mysql (and other apps...)
- Various bad practices in web applications which allow remote 
exploit/access/sql injection/xss, etc
- Trojans/viruses which target client workstations and can capture 
information without breaking into the server
- Internal attacks... Admin's who leave. Disgruntled employees..

I think it's easy to overlook that the above is often your biggest 
source of risk and continue polishing something which is normally pretty 
resistant to external attack.  As a rough rule of thumb I can only think 
of perhaps a tiny handful of exploits in the last few years which would 
have allowed remote breakin to a non hardened box running your usual 
remote access services, say Apache or email or similar (I will discount 
Bind and Sendmail from this analysis...).  However, lots of unix boxes 
have been rooted through simple holes in web applications and a bunch of 
distros that leave remotely accessible accounts with known guessable 
passwords...

Virtualisation is also a big step forward for helping contain the 
effects of a compromised machine - I'm very impressed with what we have 
been able to do since we started using it on all our servers..!

Good luck

Ed W




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-02-02 14:02 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-01 12:35 [gentoo-hardened] Remove toolchain? Hinnerk van Bruinehsen
2010-02-01 13:33 ` Ed W
2010-02-01 14:35 ` schism
2010-02-01 15:07   ` Shinkan
2010-02-02 11:34   ` basile
2010-02-02 13:37     ` Ed W

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox