[gentoo-hardened] Hardened Targets

[gentoo-hardened] Hardened Targets

[Shinkan]

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

Hi there !

I'm quite new to Gentoo, and I looked for something hardened that I can
control entirely from kernel build to use. So I found Gentoo-Hardened (then
I started to have less and less time... strange).
My aim is to have an hardened host which will build hardened targets.
Targets will then be deployed on real machines by installing them or by
running them on a LiveCD.
The main problem I can see from my rookie level is that I want each target
to be built with its own version of GCC/LIBC/(basethings) and its own
"snapshot" of a portage tree at a T time. I want the final target to be
buildtools-less, portage-less,
almost-everything-except-the-kernel-and-bash-less...

I don't know how to achieve that. I looked to Catalyst but I don't like some
points : it uses profiles (and I would have to maintain many profiles, which
seems hard as custom profile are not easily usable), its internal mechanic
is 'hidden', and for LiveCD or Stage4, it has a substractive behavior (it
keeps everything from previous stages from where it builds, then it unmerges
and removes things to get the final target).

I would prefer a "2 step" additive way. Step 1 : I would like to build, for
each target, a "build" dir which contains an hardened toolchain with
specified versions of GCC/LIBC/etc, Step 2 : then from this build dir I
would emerge things I need by hand from zero in a target dir, and build a
kernel.

Is someone having some ideas on that ?
Many thanks in advance :)

-- 
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: 1798 bytes --]

Re: [gentoo-hardened] Hardened Targets

[Mansour Moufid]

On Tue, Dec 1, 2009 at 5:40 AM, Shinkan <shinkan@gmail.com> wrote:
> The main problem I can see from my rookie level is that I want each target
> to be built with its own version of GCC/LIBC/(basethings) and its own
> "snapshot" of a portage tree at a T time.

You can specify versions by masking with Portage. For example, if you
don't want gcc 4, then you would do:
# echo ">sys-devel/gcc-4" >> /etc/portage/package.mask

As for Portage "snapshots", you can get those from the Gentoo mirrors
by date, similar to how you did during the installation process. Just
don't emerge --sync. You probably do want to apply GLSA updates though
(see: glsa-check).

> I want the final target to be
> buildtools-less, portage-less,
> almost-everything-except-the-kernel-and-bash-less...

You can start by adding the "minimal" USE flag to make.conf. Then,
once you're sure everything you need is installed, unmerge everything
you don't need (gcc, etc.). I'm sure there's a trick to get Portage to
unmerge everything in the sys-devel category, which others might be
able to help with.

You really shouldn't unmerge Portage, but if you want to, it should be
the last step -- coming *after* emerge -uUDN world && emerge
--depclean && revdep-rebuild. After which you can safely rm -drf
/usr/portage.

> I would prefer a "2 step" additive way. Step 1 : I would like to build, for
> each target, a "build" dir which contains an hardened toolchain with
> specified versions of GCC/LIBC/etc, Step 2 : then from this build dir I
> would emerge things I need by hand from zero in a target dir, and build a
> kernel.

If you want one kernel per build, then it seems to me you will need to
use chroots, similar to how you chrooted to /mnt/gentoo from the
Gentoo installation environment. For example, start with mkdir -p
/var/target/1 /var/target/2, etc., each of which would be analogous to
/mnt/gentoo. In this case, replace the root directories (``/'') I
mentioned above with ``/var/target/n'' as needed, e.g.
/var/target/1/etc/portage.mask, etc.

Hope this helps.

-- 
Mansour Moufid

Re: [gentoo-hardened] Hardened Targets

[Shinkan]

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

2009/12/1 Mansour Moufid <mansourmoufid@gmail.com>

>
> You really shouldn't unmerge Portage, but if you want to, it should be
> the last step -- coming *after* emerge -uUDN world && emerge
> --depclean && revdep-rebuild. After which you can safely rm -drf
> /usr/portage.
>

I get the way you would do the things, but that's quite the same thing that
catalyst do behind the scene.
But it uses a cache system that avoid re-emerging too often.
That's chrooting a stage3, emerging fancy features, then removing others,
all of this according to profiles.
I thing that's not very maintainable and that's error prone (because you're
not sure of what is unmerged, or what dependencies it could break).

Anyway, thanks for your help that brings fresh meat to me.
I'm interrested if there's a magic command to unmerge & clean every dev
related things once system is built.

ONE OFF-TOPIC MORE GENERAL QUESTION :
Is there a gentoo hardened toolchain with SSP and PIE BEFORE gcc 4 ?

-- 
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: 1563 bytes --]

Re: [gentoo-hardened] Hardened Targets

[Mike Edenfield]

On 12/1/2009 9:36 AM, Shinkan wrote:

> ONE OFF-TOPIC MORE GENERAL QUESTION :
> Is there a gentoo hardened toolchain with SSP and PIE BEFORE gcc 4 ?

The previous gcc-3.4 based toolchain also supported SSP and PIE, though 
the SSP implementation was significantly different.  gcc 4.x only went 
"stable" on hardened profiles recently.  (The hardened SELinux profile 
is still using gcc-3.4.6, in fact, though I'm hoping that's just an 
oversight.)

--Mike

Re: [gentoo-hardened] Hardened Targets

[Ed W]

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

Shinkan wrote:
>
>
> 2009/12/1 Mansour Moufid <mansourmoufid@gmail.com 
> <mailto:mansourmoufid@gmail.com>>
>
>
>     You really shouldn't unmerge Portage, but if you want to, it should be
>     the last step -- coming *after* emerge -uUDN world && emerge
>     --depclean && revdep-rebuild. After which you can safely rm -drf
>     /usr/portage.
>
>
> I get the way you would do the things, but that's quite the same thing 
> that catalyst do behind the scene.
> But it uses a cache system that avoid re-emerging too often.
> That's chrooting a stage3, emerging fancy features, then removing 
> others, all of this according to profiles.
> I thing that's not very maintainable and that's error prone (because 
> you're not sure of what is unmerged, or what dependencies it could break).

I haven't looked, but this isn't the way I understand Catalyst to work?

What it should be doing is exactly what you would do if you wrote your 
own scripts (It's basically just a fancy wrapper).  So look at the 
TinyGentoo instructions: http://en.gentoo-wiki.com/wiki/TinyGentoo and 
this gives you the basic principles

I use a kind of similar process to build my builds.  I use a chroot as 
the build system (basically just a roughly right stage4 build), then I 
chroot into that and build packages for everything that I need, then I 
install all the packages into some build directory and that becomes the 
new installation. This means that the destination doesn't need portage 
or gcc, etc (it's a very small and bare installation).  You can also 
build packages to distribute with qpkg, etc.

Also see alpine linux?

> I'm interrested if there's a magic command to unmerge & clean every 
> dev related things once system is built.

Sure - just "emerge -C yourstuff" and it's gone.  You can easily get a 
list of packages that were installed, you just need to know which ones 
you want to remove?  I personally build mine the other way and install 
only the stuff I need

What I *expect* catalyst to do is to build a stage1-4 build environment, 
then use that stage4 build environment to build another stage1-4 
distribution where each stage builds incrementally?  Never used 
catalyst, but that's what I would expect to happen.  The logic being 
that you first build the build environment, then use the build 
environment to build the final distribution.  You could jump straight in 
and script all the steps directly yourself if you dont need the 
flexibility of catalyst?

> ONE OFF-TOPIC MORE GENERAL QUESTION :
> Is there a gentoo hardened toolchain with SSP and PIE BEFORE gcc 4 ?

Actually that's the gcc3.4.6 which was stable only a few weeks ago.  
However, as has been mentioned it's not the same SSP as the new GCC4.4. 

There is a hardened overlay for gcc4.4 and I'm using this right now in 
conjunction with uclibc and I have to say it's working very nicely with 
fairly few workarounds needed (Python and sandbox mainly).  I'm actually 
unsure why it's not already migrated to gentoo package masked, however, 
I would suggest you base any new work on that overlay if you are 
starting now

Good luck

Ed W

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

Re: [gentoo-hardened] Hardened Targets

[Shinkan]

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

2009/12/1 Ed W <lists@wildgooses.com>

>
> So look at the TinyGentoo instructions:
> http://en.gentoo-wiki.com/wiki/TinyGentoo and this gives you the basic
> principles
>

Yeah, I'm more fond of things like this.
I don't need uclibc, or embedded things ... I just use a dedicated host as
my "build" chroot.
I based my thoughts on http://www.gentoo.org/proj/en/base/embedded/handbook/
The problem now is that I want some targets to run with "previous version"
libc, where previous comes for "anterior to my host libc/gcc".
So I think you have to compile with correct "previous version" gcc.
So I deduced I have to build a special env with old gcc + old libc to build
my old libc based target.
Is that the case ?
Or can I just emerge --root=/mytarget --configdir=/mytargetconfig
glibc-oldversion with my current host, and target will run correctly based
on glibc-oldversion ?


>
> I use a kind of similar process to build my builds.  I use a chroot as the
> build system (basically just a roughly right stage4 build), then I chroot
> into that and build packages for everything that I need, then I install all
> the packages into some build directory and that becomes the new
> installation. This means that the destination doesn't need portage or gcc,
> etc (it's a very small and bare installation).  You can also build packages
> to distribute with qpkg, etc.
>

I'm quite near that instead that I want to directly emerge in my target
build instead of building packages then unpacking them to my target.
Why is the chroot useful ? Why don't you just emerge onto your target with
you host ?


>  I personally build mine the other way and install only the stuff I need
>

That's I want to do to. I would prefer not unmerging things.
I prefer asking myself "what should I add to nothing to have a bare minimal
working system" instead of "what sould I remove from a full build-capable
stage4 without breaking things".


>
> What I *expect* catalyst to do is to build a stage1-4 build environment,
> then use that stage4 build environment to build another stage1-4
> distribution where each stage builds incrementally?
>

Catalyst build stages from 1 to 4 starting with a chrooted stage3 which
serves as a build platform.
But as soon as you talk about "stage" in Gentoo, you comes with portage, gcc
and many build stuff I don't want in my target.
Catalyst use a "when stage4 is built, unmerge and remove a big list of
things like gcc" logic, which I don't want.
At least, that's what I figured out.

Anyway, thanks for the tips that was quite useful.


-- 
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: 4284 bytes --]

Re: [gentoo-hardened] Hardened Targets

[Ed W]

Shinkan wrote:
> Catalyst build stages from 1 to 4 starting with a chrooted stage3 
> which serves as a build platform.
> But as soon as you talk about "stage" in Gentoo, you comes with 
> portage, gcc and many build stuff I don't want in my target.

You know more than me, but are you sure it's not just a case that you 
are looking at a bad example?  I see no reason why you wouldn't just 
produce a new template which simply installs only the things you need?  
eg in your case you could simply create an incredibly "fat" stage1 which 
is all the software you need and no gcc, just stop there..?

I was under the impression the stage1-4 is all arbitrary and just the 
result of you using 4 template files, nothing else? (use only one stage 
or use 7 stages?)

Good luck

Ed W