Advice solicited for a complex configuration

[mhill]

I am a complete n00b to Gentoo. I've used RPM-based distros for several years, but for a while now I've been looking for a way off the too-many-dependencies-when-upgrading-packages treadmill. I've investigated a lot of alternative distros, and settled on Gentoo with its portage system as the most likely to satisfy my needs. So much for the background.

In addition, while I'm not quite ready to migrate my main Linux workstation to Gentoo yet, I am planning to build a new Gentoo firewall to replace my current OpenBSD one. As such, one of my ideas is to use a dual-boot system with two HDD's, such that one boots up a build/upgrade system and the other boots up the "production" firewall/network gateway system. When I am upgrading, my internal network will not be connected to the outside world, and the production drive will be mounted so I can write binaries to it (I don't plan to have any C compiler or many other build tools available on the production side). When the production side is booted up, it will not contain any information (ideally, tho it will be hard to prevent it showing up in /dev) about the existence of the build drive. Clear so far?

I would like advice on how to install Gentoo for the first time on this system. So far I've installed the stage 3 tarball on the build drive, and was thinking it would be appropriate to install the stage 1 tarball on the production drive and try to build it up from the build drive. How hard will it be to do the latter task? To have emerge download & build s/w on the build drive, but install it on the production drive?

TIA for any help you can provide.
_________________
Michael Hill

Desktop: Intel i7-3930K, 16GB DDR3, 1x 240GB SSD, 2x 3TB SATA, GeForce GTX660Ti, TSSTcorp SH-S203N

[saint_abroad]

Hmm, I see what you're trying to do with the whole build/production idea, bit difficult to implement tho. The main difficulty is getting portage to track 2 separate builds. It would have to do this as there wouldn't be portage/gcc on the production disk. The only way I can see of doing it would be to have identical build and production disks except for: portage, gcc, kernel. Now I've never done this before so I'm winging it a little...

First of all I'd read the following:
http://www.gentoo.org/doc/en/gentoo-x86-install.xml
http://www.gentoo.org/doc/en/gentoo-security.xml

Then I'd start on the build-disk . I would have this as the secondary disk, hdb. Five partitions:
1) /boot/ reiserfs noauto,notail,noatime
2) swap
3) / reiserfs notail,noatime
4) /var/ reiserfs notail,noatime,nodev (about 1 gig needed)
5) /tmp/ reiserfs notail,noatime,nodev,nosuid,noexec
Note no separate /home/ but you shouldn't have any users on a firewall anyways. I would then compile the system and install any needed firewall stuff (eg loggers, chron, snort) without optimizations using (as close to) default USE flags (look in security link above). Do not install non-essentials such as X, these are hazards. Then compile the kernel with reiserfs, ext2, and the minimum needed to boot properly. Edit the various config files so they are correct. Now setup grub on the mbr of the primary disk (to be the production-disk) with the grub files in the build-disk's /boot/ bearing in mind that there will be two boot options, with two kernels, one on each disk. Make the production-disk the default boot option. Now setup chron to reboot the computer every day at a quiet hour. Finally:
rm -dfr /usr/portage/distfiles/*
rm -dfr /var/tmp/*
Reboot to check that you can boot to build-disk and that things are working.

Once the build-disk is up, its time to start work on the production-disk, hda. Don't use the livecd, just use the build-disk. Partition hda:
1) /boot/ ext2 noauto,noatime
2) swap
3) / ext2 noatime
4) /var/ ext2 noatime,nodev (can be <1 gig, as no compiling will be done)
5) /tmp/ ext2 noatime,nodev,nosuid,noexec
Notice now ext2 instead of reiserfs. Now simply mount (to /mnt/) and copy recursively /root/ , /var/ and /tmp/ from build-disk to production-disk and mount production-disk's /boot/ (as /boot/). Now the production-disk kernel will have to be compiled, this time leaving out reiserfs so that it is *extremely* difficult to read the build-disk . You may be able to leave out devfs on the production-kernel so that they can't even see the build-disk but I never tried to go that far, and it may break if you don't create the proper devices yourself . Have a go if you're really serious about security cos you can always boot with the build-kernel (if you have physical access to the machine) and remake the production-kernel if it gets too hairy.

Finally, reboot the computer into the production-kernel (with production-disk's / ) and make sure things are working before finally using portage to remove gcc, binutils and python in that order (tho you may have to copy reboot over from the build-disk again). I never tried to remove any of those, cos it would mean that I wouldn't be able to install anything so it may fail on python but as long as gcc is gone... . You now have a borked install on the production-disk that can't compile or copy anything (or delete, or list, or... well you get the picture, not much). WARNING: Make sure you don't remove the build-disk's gcc, binutils, python or else you'll need a reinstall from the beginning :/ .

Now if you decide that you want to update the software on your firewall simply boot to the build-disk, update that, mount (to /mnt/) and delete recursively the production-disk's /root/ , /var/ and /tmp/ then repeat the last paragraph.

The steps above may seem long but you'll have a firewall that (I think) only a super-cracker can subvert and is resilient (restore corrupted/cracked production-disk from build-disk). Of course, its up to you to keep the root password secure, if thats compromised, then all is for nothing. If anyone sees any way of doing damage to this system please point it out, cos I'm sure security comments will benefit anyone else reading this. In any case, it is enough of a deterrent, unless you're a bank, heh.

In reality, if it was my home network I wouldn't go to the trouble of separate build-disk and production-disk. Usually as long as you keep the software to a minimum, update frequently, reboot every day, have only root on the machine, and expire the random >8 digit password every day, *very* few people in the world would be able to crack your firewall and all you'd need to worry about are DOS/flood style attacks.
_________________
I work for fun. But only as a means to an end.

[mhill]

saint_abroad, thanks for your long & well-considered reply. I think you've actually made a good case for not going to such extreme lengths for a home firewall. (Or at least not until I've gained quite a bit of experience running a normal Gentoo installation!)

OTOH, I just recently learned about distcc, and it occurred to me: Is it possible to run distcc in a configuration where it does NOT run a local compile, but only a remote? That way you could still avoid having the compilation structure on the production firewall, leaving it on a "Gentoo build server". This is rather an academic point, however (as I've realized since my first post), since rootkits render the non-presence of a C compiler moot. I'd still be interested in any further thoughts on this.
_________________
Michael Hill

Desktop: Intel i7-3930K, 16GB DDR3, 1x 240GB SSD, 2x 3TB SATA, GeForce GTX660Ti, TSSTcorp SH-S203N

[mpsii]

distcc.samba.org

Read the manual for more extensive, but basically I think if you set the DISTCC_HOSTS enviroment variable to not include the local system, it effectively does only remote compilations.

[mhill]

Thanks for the reply. That was the impression I had received, too, from reading the documentation. I don't imagine it's something that's done very often, though, so I wasn't surprised that the manual didn't mention whether it was possible. I'd be interested in hearing definitively if somebody has actually used distcc in that manner successfully.
_________________
Michael Hill

Desktop: Intel i7-3930K, 16GB DDR3, 1x 240GB SSD, 2x 3TB SATA, GeForce GTX660Ti, TSSTcorp SH-S203N